cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <>
Subject Re: [RT] Virtual Sitemap Components
Date Fri, 16 Jul 2004 14:20:05 GMT
Marc Portier wrote:

> Sylvain Wallez wrote:
>> Ralph Goers wrote:
>>> I must admit, I am completely confused.  The question was posed 
>>> earlier as to what the difference between virtual sitemap components 
>>> and resources are, to which I haven't seen an answer.
>>> It would seem that they are close enough conceptually that having 
>>> both of them is just going to confuse users even more. Cannot 
>>> resources be fixed to get rid of some of the shortcomings instead?
>> The "ratified bug" mentioned by Vadim, is that resources where 
>> initially meant to be endpoints only (i.e. must end with a 
>> serializer) and implemented as such in the original compiled sitemap 
>> engine whereas a bug in the interpreted sitemap engine (that exists 
>> for more than 2 years now) allows them to be similar to subroutines 
>> and therefore not being limited to being endpoints, since you can 
>> return from a resource to the calling point.
>> So, in this regard, virtual components and resources are very close. 
>> IIRC, Stefano once said that virtual components are what resources 
>> should have been from the start. So we can consider that once we'll 
>> have virtual components, resources will be deprecated.
> translating this into 'why would I use them?'
> virtual components would thus introduce something which is related to 
> strong-type checking, a resource would be declared (and checked) to 
> function as either a generator, a transformer, a serializer or a 
> complete pipe (Q: will this last thing be something like virtual-read?)

A: FWIW, and IMHO, resources should become this last thing. In main 
sitemap you do some kind of logic / selectors / etc, and then you have 
an option to call "resource", which should assemble be complete g / (t)* 
/ s pipeline.


> today you need to check in the resource's internals to apply it in a 
> correct way to build up a new pipe (of course some personal naming 
> convention helps in that regard)
>> The important difference also is that virtual components will be 
>> inherited by subsitemaps, which is not the case for resources.
> which makes sense from usability perspective as well: their contract 
> becomes more rigid, so you can more easily pass them down to users 
> that (potentially) don't have access to those internals
> HTH,
> -marc=

View raw message