Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
Ok, I guess that we have to go for your solution of having several
variants of the source resolver:
SourceResolver.ROLE + "/static" - resolve relative to the defining
manager, and is implemented as I indicated above. We could modify
CoreComponentManager so that it automatically creates static resolver
for each manager.
SourceResolver.ROLE + "/dynamic" - resolve relative the current sitemap
and uses EnvironmentHelper.resolveURI (or something similar), undefined
and throws an exception if used when there is no current processor.
Then we should try to change all uses of the current source reolver to
the new ones and in principle deprecate the CocoonSourceResolver,
(although a warning in the documentation might be enough).
WDYT?
Why different components? What about using different protocols?
The whole question is about what to resolve relative URLs against so I
don't see how different protocols would help. Furthermore I think that
it should be the component designers problem to decide what the
behaviour should be for different uses of relative URLs for the
component rather than the users problem.
Without a protocol you have the same behaviour as currently and using
"static:" (or a better name) it's resolved relative to the definition.
So no changes of the existing components. Just a protocol switch where
appropriate.
The current behaviour is flawed as we already know from e.g. the case
with the I18N transformer where dynamic resolution is used when static
is what would have been expected. With lazy loading things get even
worse as resolution during the setup phase also can become dynamic.
It is time that we solve this problem once and for all.
/Daniel
