cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: [RT] Virtual Sitemap Components
Date Mon, 19 Jul 2004 14:06:32 GMT
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


Mime
View raw message