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.
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.
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...
Sylvain
-- Sylvain Wallez Anyware Technologies http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
