cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <...@outerthought.org>
Subject Re: [RT] Virtual Sitemap Components
Date Fri, 16 Jul 2004 14:10:18 GMT


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?)

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=
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo@outerthought.org                              mpo@apache.org

Mime
View raw message