Sylvain Wallez wrote:
Unico Hommes wrote:
Sylvain Wallez wrote:
<snip/>
We already have this src="" attribute which currently is a raw string. Does this mean that we will enforce the contract on this by explicitely stating that it's a URI that will be resolved in the local context where the instruction is written?
We have to check if all of our current components use src as an URI.
I've often thought that the signature of the setup() method was wrong. The src parameter is passed as a String, the component is free to interpret it as anything it wishes. But I think this parameter was really only meant to ever be interpreted as a Source object. So instead of setup(SourceResolver resolver, Map om, String src, Parameters pars) the method should be setup(Source source, Map om, Parameters pars). That also unambiguously defines the meaning of the src attribute.
Agree. But this parameter has been underspecified for so long that it may well be the case that some people use it as a row string.
No pain, no gain ;-)
Mmhh... what if other parameters are also URIs?
Easy. There is no way for a sitemap to interpret it as anything but a plain string. If a component wants to interpret it as a Source it uses its SourceResolver.
Sure.
We'll have a special Source protocol that allows to get FileSources relative to the calling sitemap.
Er... what is the "calling sitemap" when there's a chain involving several sitemap, e.g. in a virtual component defined in a parent sitemap that has been called through a block? IMO, an absolutizer input module is better suited as it is evaluated at sitemap execution time (and thus in the context of that sitemap) whereas we don't know when a component will decide to use the SourceResolver to get a Source object from a String.
Ah! I understand now. I was wondering about that in your other email. You are totally right.
-- Unico
