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 Sun, 18 Jul 2004 18:47:51 GMT


Sylvain Wallez wrote:

> Marc Portier wrote:
> 
>>
>>
>> Sylvain Wallez wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>>> Sylvain Wallez wrote:
>>>>
>>>>> Carsten Ziegeler wrote:
>>>>>
>>
>> <snip />
>>
>>>>>
>>>>>> There were some mentions in the past, that a VSC can contain any

>>>>>> sitemap
>>>>>> component, so even actions, matchers and selectors are allowed in
>>>>>> the definition of the VSC.
>>>>>>
>>>>>> So, first question is: do we want this?
>>>>>>
>>>>>> (I would say: no)
>>>>>>  
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>> I would say yes! Forbidding control structures in virtual 
>>>>> components would greatly reduce their usefulness.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> i agree with you, but do you think it makes sense to use everything? 
>>>> I would say that just selection and action would be useful, but 
>>>> matching and redirection would be harmful.
>>>
>>>
>>>
>>>
>>>
>>> I don't see how matching could be harmful if selection is not, as 
>>> they're close to each other and only do tests on the environment.
>>>
>>> Redirects, actions and flowscript calls, however, break the semantics 
>>> of pipeline components which should not modify the system state, at 
>>> least until the pipeline execution starts.
>>>
>>
>> again from the user/contract perspective:
>>
>> redirects don't match any of isAGenerator, isATransformer, 
>> isASerializer so should be ruled out in any of those type of virtual 
>> components
> 
> 
> 
> +1
> 
>> if allowed at all, they could only make sense in something like a 
>> virtual-read (which as Vadim suggests (at least if I got that right) 
>> could be the second live of resources?)
> 
> 
> 
> 
> Mmmh... a reader cannot currently perform a redirect, as it has no 
> access to the redirector object. So strictly speaking, allowing a 
> redirect in a virtual reader breaks the reader's semantics.
> 

thx for clarifying

> On the other hand, a reader terminates the sitemap execution and 
> produces the response. And we can consider that issuing a redirect _is_ 
> a response. In this regard, _any_ sitemap instruction could be allowed 
> in a virtual reader, contrarily to other virtual components.
> 

indeed, the 'response-production' was largely the abstraction I was 
making to categorize read and redirect in the same family

>> flowscript calls fall under the same observation?
>>
>> striclyt speaking actions don't I think: even with an action in place 
>> you can assure to be building up a part of a pipe that functions as a 
>> G, or T, or S
>>
>> however, I wouldn't, from a user prespective, be surprised if for 
>> technical reasons the flexibility of these virtual components would be 
>> limited and exclude the use of actions
>>
>>> Calling a resource should be possible, even if resources make less 
>>> sense with virtual components, provided that the resource contents 
>>> follow the rules for a virtual component.
>>>
>>
>> I'm with Vadim here: resources v2 should be virtual-reads building up 
>> complete pipes, I see no other use if VPC's are there
> 
> 
> 
> Well, I changed my mind a bit overnight: if we consider that VPC somehow 
> deprecate resources, let's just keep them as they are today, so as not 
> to have backwards compatibility problems, and forbid their use in VPCs. 
> That will slowly move them towards the graveyard...
> 

+1, the VPC's as discussed here provide enough added value to make the 
transition happen

(assuming  that your proposal now includes to have virtual-reads as a 
forth type of VPC's?)

regards,
-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