Carsten Ziegeler wrote:
Sylvain Wallez wrote:
<snip/<
Or maybe a good solution can be to combine both approaches: the sitemap engine will use the mini-processor approach, and component lookups (which are not that often used) lead to the creation of a simple wrapper object implementing the Java interface, but that doesn't care about caching as SWT and ZipArchiveSerializer don't care about it.
Yes, this sounds like a good compromise. I really think that
the usage of VPC should not be any different than using
"usual" pipeline components - it should be transparent.
I agree that looking up sitemap components outside of the
tree processor does really happen not very often, so
providing such a wrapper is the best way to go.
Cool, we found an efficient solution :-)
So, for implementation VPC the only missing piece is resolving
of relative sources, right?
Yep. Problem is that currently the "src" attribute is a raw string and so we don't absolutize URIs at the place where they're written but at the placed where they're used, i.e. potentially in another context.
So we can enforce the contract of "src", stating that it *is* a URI, and thus absolutized by the sitemap engine at statement execution time. We have to perform extended checks that no component uses it another way though. Or we could have a marker interface extending SitemapModelComponent that could be used to distinguish the component's expectations.
We also need an absolutizer input-module that allows people to absolutize URIs used in other attributes than "src". That works pretty well using the nested variables resolution we have now, e.g. <map:parameter name="blah" value="{absolutize:data/{1}.xml}"/>
WDYT?
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
