Carsten Ziegeler wrote:

Vadim Gritsenko wrote:


Carsten Ziegeler wrote:



I'll try to summarize what we've got so far (as far as I

interpret this

thread :) ):

A VPC (virtual pipeline component) is like a macro (I didn't find a better term);




I'm not sure I agree with this approach... I prefer to see VPC opaque to the label processing, internals of the VPC should not be considered when processing a view request.



Can you please explain what you mean by this?



I mean: do not allow labels on internals of VPC / do not process such labels. For the purposes of view creation, consider VPC as an atomic component.



Also, if you have virtual generator "x" defined, what will be the result of serviceManager.lookup(Generator.ROLE).select("x")?



A VPCGenerator object implementing the generator interface? I haven'T
thought about it very well, but I guess it's possible (if we only
allow pipeline components (G,T,S) for virtual components than this
is easy anyway; but as we allow more (Actions,Matchers,Selectors)
this might be slightly more difficult).



The part which makes it more difficult is most intriguing, though... VirtualGenerator then becomes container for the instance of ProcessingNode plus some code to build and manage (get key/validity) pipeline... No changes to the sitemap treeprocessor will be needed then, provided that source resolving issues are ironed out.



The VPC from above resolves two sources (the src and the stylesheet).
The stylesheet should imho be resolved relative to the sitemap where the VPC is defined.
The src ("blah") should refer to a source that is relative to the sitemap of the Usage.




That's what would I expect, and most users, I guess, too would expect this behavior. How can we achive this?



Oh, that's easy :) Before we pass the source to the virtual component,
we resolve it, creating an absolute path.


Well, it can be easy if and only if source can be passed as src parameter, and parameter contains full sitemap path to the source. If source, or several sources, is(are) passed through some other parameter(s), you won't know this. And if src parameter for the virtual generator contains partial path, you also won't know this. Quick example (note how {src} is used):


<map:generator name="i18n">
   <map:match type="i18n" pattern="resources/{src}.*.xml">
       <map:generate src="{source}"/>
   </map:match>
</map:generator>

Other examples are FragmentGenerator, CalendarGenerator, Oracle BLOB generator, etc.

What I think is that when virtual generator is set up, it executes its ProcessingNode, and it should then pass declaring sitemap's source resolver. As a result of executing processing node, pipeline fragment will be built. When components in this fragment are set up, current sitemap resolver should be passed into their's setup() methods. Will this, or something similar, work? I might be missing some usecase here...

Vadim



Reply via email to