You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Michael Homeijer <M....@devote.nl> on 2002/03/06 08:34:23 UTC
RE: Pipe-aware Selectors [was Re: XML-Based Selection (Redirect
Serializer?)]
Hi Stefano,
Could you please have another look at the solution described by Bruno Dumon
in the mailing list and comment on it.
I'd really like to know what you think about it.
It seperates the small incoming parts of data from the outgoing flow,
doesn't change any cocoon interfaces, and you will be able to integrate
results from processing incoming data into the pipeline again.
TIA,
Michael
> -----Original Message-----
> From: Stefano Mazzocchi [mailto:stefano@apache.org]
> Sent: dinsdag 5 maart 2002 21:27
> To: cocoon-dev@xml.apache.org
> Subject: Pipe-aware Selectors [was Re: XML-Based Selection (Redirect
> Serializer?)]
>
>
> Daniel Fagerstrom wrote:
>
> > The pipe-selector (ideas about a better name?) would look
> something like
> > this:
> > <pipe-selector type="xpath">
> > <when test="expr1">
> > <!-- pipeline fragment -->
> > </when>
> > <when test="expr2">
> > <!-- pipeline fragment -->
> > </when>
> > ...
> > <otherwise>
> > <!-- pipeline fragment -->
> > </otherwise>
> > </pipe-selector>
> >
> > The general idea is that the pipe-selector buffers it input
> in e.g. a
> > DOM-tree, then the tests can be applied to the buffered
> input. The pipeline
> > fragment in the first when clause where the test succeed is
> then feeded with
> > the buffered input, and its output is send to the pipeline
> component after
> > the pipe selector.
>
> Ok, I see your point clearly.
>
> > How can this be implemented?
> >
> > The pipe-selector is a transformer (i.e. implements the transformer
> > interface) extended with a method that lets the sitemap
> constructor send an
> > object to the pipe-selector that takes care of the tests
> and the pipeline
> > fragment construction for the selected when clause in the
> pipe-selector.
> >
> > The actual tests can implement the selector interface if it
> is ok to put the
> > DOM-tree with buffered input in the objectModel. A possible
> issue with this
> > is that the tests in the selector are performed after that the whole
> > pipeline is constructed. This might give the unintuitive effect that
> > components later in the pipeline that effects the objectModel and is
> > executed during sitemap construction time are executed
> before the test in
> > the pipe-selector.
>
> Hmmm, I don't think this behavior should extend Transformer's, smells
> like a bad design choice to me.
>
> > The sitemap stylesheet constructs a class for each
> pipe-selector instance in
> > the sitemap. This class contains a method that returns a
> EventPipeline. The
> > method executes the tests and constructs and returns an
> EventPipeline for
> > the first when clause that succeed. The EventPipline starts
> with a generator
> > puts the DOM-tree in the objectModell in a DOMStreamer.
> >
> > class PipeSelectorInternalPipeN01234 {
> > public EventPipeLine constructPipe(SitemapRedirector redirector,
> > Environment environment,
> > List listOfMaps) { ... }
> > }
> >
> > The code in sitemap_xmap for constructing the pipeline that
> contains a
> > pipe-selector is like that for any pipeline that contains a
> transformer,
> > with the difference that the "pipe-selector transformer" is given an
> > instance of its PipeSelectorInternalPipe class.
> >
> > The algoritm for the PipeSelector is:
> > * Its input is connected to a DOMBuilder.
> > * The DOM-tree is put in the objectModel.
> > * The constructPipe(...) method of the PipeSelectors
> > PipeSelectorInternalPipe class is executed.
> > * The returned EventPipeline is connected to the output of
> the PipeSelector
> > and the EventPipelines process method is called.
> >
> > I hope that the description above is comprehensible.
>
> I'm *seriously* worried about the need to buffer the input.
>
> > > 2) how does this impact performance? how does this
> impact caching?
> > >
> > > [the first impacts the system usage, the second the interface of
> > > Selectors or PipeSelectors]
> >
> > The simplest way to implement cashability is to base the
> cash key generation
> > on _all_ of the pipeline fragments in the when clauses.
> This is fairly
> > unsatisfying as it implies the construction of all of the
> pipeline fragments
> > instead of only the one that is selected. It will also decrease the
> > possibility to cash the PipeSelector and lead to unnecesary
> recalculation
> > based on changes in "when clauses" that was not selected.
> The problem is
> > that when the generateKey() method is called it is not
> known what "when
> > clause" that will be choosen. If we however had a method like
> > generateKey(key), where "key" is the hash key for the
> pipeline fragment
> > before the PipeSelector, "key" uniquely determines the input to the
> > PipeSelector and thus what "when clause" that will be selected, this
> > information: the map from key to "when clause", could be
> stored and the used
> > to compute the cach key for the PipeSelector only based on
> the pipeline
> > fragment in the _selected_ when clause.
>
> Sorry, I think I lost you here. :/
>
> > Performance: it would of course better to not be forced to store the
> > SAX-events in DOM-tree, but I do not see much choice.
>
> Well, this is not a problem since XSLT processing works this
> way anyway,
> but an XPath engine can be made much more incremental than a XSLT-one.
>
> Also, it might be possible that not much load is given to these pipes
> since they are mostly used in data INPUT which is normally much less
> than data OUTPUT in any site.
>
> > The main use for the
> > PipeSelector will probably be to make selection based on
> XML input to Cocoon
> > and on the output from transformers with side effects, I
> would guess that
> > for these cases it will most of the time be quite small
> documents. Besides
> > the need for buffering I do not think there should be any sources to
> > performance botlenecks in a PipeSelector, but I do not know
> enogh about the
> > internals of Cocoon to know for sure.
> >
> > What do you think?, would something along this lines work?
>
> Yes, I think it might work, but I still can't see if this requires a
> change in the Selector interface or if another sitemap
> component must be
> added.
>
> What do you guys think?
>
> --
> Stefano Mazzocchi One must still have chaos in oneself to be
> able to give birth to a dancing star.
> <st...@apache.org> Friedrich Nietzsche
> --------------------------------------------------------------------
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
...
> I see three solutions:
>
> 1) ignore the proposal (but we must find a way to implement the same
> functionality without hacks!)
> 2) change the Selector interface
> 3) add another pipeline-aware routing sitemap component
>
> Tough decision indeed!
Yup, I have the same feeling.
There is a real need, and it seems that the envisioned solutions don't fit
that cleanly in the global picture yet.
This makes me think of the (apparent?) dichotomy in Cocoon between Event and
Stream pipelines.
Cocoon uses XML internally, but has to interface to a request coming in and
a result to give, all *not* as SAX events.
IMHO it could be possible (but not necessarily desirable) to achieve all
that Cocoon does now with Event+Stream pipelines only using Stream
pipelines, and this is what I've seen many do.
For example, you can check for authorization to see parts of a file in the
event part, with an Action and XSP tags that show-hide parts of content; but
you can also pipe the request in SAX and have a Transformer or even simple
XSL filter the stream based on the stream content itself. Should the Stream
contain only content, or also content metadata that shapes the content
itself? Are there, semantically speaking, different types-levels of content?
It seems that the dual nature of the processing in Cocoon is starting to get
tested by sensible argumentations.
What do you think?
BTW, Java, an Object language, that has primitive types. A hack? I don't
have the answer.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
>
> From: "Stefano Mazzocchi" <st...@apache.org>
>
> > Nicola Ken Barozzi wrote:
> >
> > > It seems that the dual nature of the processing in Cocoon is starting to
> get
> > > tested by sensible argumentations.
> >
> > I'm sorry, Ken, but I don't get your point about this 'dual nature', can
> > you elaborate more?
>
> Cocoon has
> Event Pipeline <-> Stream Pipeline
>
> IMHO it's not *stricly* necessary (as theory goes) to have an event
> pipeline, and the fact that Actions are not so "pure" stems from the fact
> that it makes the Event Components bleed into the original pure Pipeline
> arena.
>
> For example, instead of selecting between two pipelines and generating from
> the choosen one, I can generate from both and filter only the relevant tags.
> Not auspicable, but possible.
Ok
> You can use Actions to act on the request (event pipeline), or you can use
> the RequestGenerator and have a side-effects Transformer do the same action.
>
> You can use some sort of Dispatching instead of Matching.
>
> Since there is a possibility in Cocoon to do things in at least two ways
> because of this, sometimes it happens that it comes natural to think that
> there needs to be a pure duality between the two pipelines that now lacks.
>
> Selector : Redirection or Rerouting
> Action : Side-Effect-Transformer
> Matching: Dispatcher-Adapter
>
> It *seems* that one could build a Cocoon without the pure Event Components.
> Like one could write Java without primitive types, and use only objects.
Yes, exactly. But they were introduced for speed concern mainly.
Smalltalk didn't have them and it was slow so they perceived it as a way
to improve performance by lowering the OO abstractions and creating OO
encapsulation... but we all see this was kind a hack, expecially looking
at the Collection API, lack of generics and the layers of Reflections
that were added over the versions.
> But IMHO there is a big difference here.
> We have the opportunity of separating the flow (events) from the pipelines.
I don't see the reason for this. I feel that having two types of
component is a feature, not a bug and doesn't create an architectural
problem... rather the opposite: it makes it easier for people to choose
how to separate concerns between logic that works 'in the pipe' and
logic that works 'on the pipe'.
Until now, we didn't find the way of having pipe routing based on pipe
content, but just because there is some overlap between the two world in
this particular behavior, I don't think this creates a need to remove
the separation between the two classifications.
> How are these Pipe-aware Selectors, Dispatchers, Adapters and side-effect
> Transformers going to fit with the future Flowmap+Sitemap Cocoon?
Well, the more I think about it, the more I picture Flowmaps and
Sitemaps being two instances of a class implementing the behavior of
'pipeline control'. Both will be able to mount one inside the other.
The idea is to have something like this
/ -> sitemap
/webmail/ -> flowmap
/webmail/user/folder -> sitemap
So: you *mount* a sitemap where you have more publishing needs than
web-apps needs and you mount a flowmap when you have more web-app needs
than publishing needs.
Or better: you mount a sitemap where you perceive your environment more
declarative and user driven (publishing-oriented), you mount a flowmap
where you perceive your environment more procedural and use is
server-side logic driven (web-app oriented).
If I were to describe it with java pseudo-syntax, I would use something
like this:
interface PipelineController {
this is the part that accepts the request and generate the response;
}
abstract class AbstractPipelineController {
allows other AbstractPipelineController to be mount
in the managed URI space in a cascading way
}
class Sitemap implements PipelineController extends
AbstractPipelineController {
implements the behavior using a declarative-style XML syntax mostly
oriented at stateless operations
}
class Sitemap implements PipelineController extends
AbstractPipelineController {
implements the behavior using a procecural-style code-like syntax
mostly
oriented at stateful operations, providing transparent state control
}
so it doesn't really matter how many components we add to the sitemap
because this is a polymorphic behavior and concerns are completely
separated between the two PipelineController implementations.
Sure, some overlap will remain and uses will have to find what they like
the best to implement the functionality, but at least we'll give the two
flavors that they need.
No, please, stop it right there: I know what you guys are thinking:
let's make this pluggable so that everybody makes its own
PipelineController implementation.
Berin proposed this a while ago and I still think that we should not get
into this direction until we are happy with the sitemap and the flowmap
and this will take a while.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
> Nicola Ken Barozzi wrote:
>
> > It seems that the dual nature of the processing in Cocoon is starting to
get
> > tested by sensible argumentations.
>
> I'm sorry, Ken, but I don't get your point about this 'dual nature', can
> you elaborate more?
Cocoon has
Event Pipeline <-> Stream Pipeline
IMHO it's not *stricly* necessary (as theory goes) to have an event
pipeline, and the fact that Actions are not so "pure" stems from the fact
that it makes the Event Components bleed into the original pure Pipeline
arena.
For example, instead of selecting between two pipelines and generating from
the choosen one, I can generate from both and filter only the relevant tags.
Not auspicable, but possible.
You can use Actions to act on the request (event pipeline), or you can use
the RequestGenerator and have a side-effects Transformer do the same action.
You can use some sort of Dispatching instead of Matching.
Since there is a possibility in Cocoon to do things in at least two ways
because of this, sometimes it happens that it comes natural to think that
there needs to be a pure duality between the two pipelines that now lacks.
Selector : Redirection or Rerouting
Action : Side-Effect-Transformer
Matching: Dispatcher-Adapter
It *seems* that one could build a Cocoon without the pure Event Components.
Like one could write Java without primitive types, and use only objects.
But IMHO there is a big difference here.
We have the opportunity of separating the flow (events) from the pipelines.
How are these Pipe-aware Selectors, Dispatchers, Adapters and side-effect
Transformers going to fit with the future Flowmap+Sitemap Cocoon?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Stefano Mazzocchi <st...@apache.org>.
Nicola Ken Barozzi wrote:
> It seems that the dual nature of the processing in Cocoon is starting to get
> tested by sensible argumentations.
I'm sorry, Ken, but I don't get your point about this 'dual nature', can
you elaborate more?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Nicola Ken Barozzi <ni...@apache.org>.
From: "Stefano Mazzocchi" <st...@apache.org>
...
> I see three solutions:
>
> 1) ignore the proposal (but we must find a way to implement the same
> functionality without hacks!)
> 2) change the Selector interface
> 3) add another pipeline-aware routing sitemap component
>
> Tough decision indeed!
Yup, I have the same feeling.
There is a real need, and it seems that the envisioned solutions don't fit
that cleanly in the global picture yet.
This makes me think of the (apparent?) dichotomy in Cocoon between Event and
Stream pipelines.
Cocoon uses XML internally, but has to interface to a request coming in and
a result to give, all *not* as SAX events.
IMHO it could be possible (but not necessarily desirable) to achieve all
that Cocoon does now with Event+Stream pipelines only using Stream
pipelines, and this is what I've seen many do.
For example, you can check for authorization to see parts of a file in the
event part, with an Action and XSP tags that show-hide parts of content; but
you can also pipe the request in SAX and have a Transformer or even simple
XSL filter the stream based on the stream content itself. Should the Stream
contain only content, or also content metadata that shapes the content
itself? Are there, semantically speaking, different types-levels of content?
It seems that the dual nature of the processing in Cocoon is starting to get
tested by sensible argumentations.
What do you think?
BTW, Java, an Object language, that has primitive types. A hack? I don't
have the answer.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by giacomo <gi...@apache.org>.
On Thu, 7 Mar 2002, Stefano Mazzocchi wrote:
> giacomo wrote:
>
> > In fact I don't think we can change the Selector interface as it is
> > clearly stated what a Selector is and how it works (read: not a pipeline
> > component). It doesn't mess with the SAX event in a pipeline (also for
> > backwards compatability).
>
> Yes, that's a good point, but the semantics looks so similar that might
> be misleading... hmmm, I still don't know if this is a good idea or not.
>
> > Maybe there needs to be other sematic in the sitemap to achieve what was
> > requested (honestly I have not had the need for such things so I don't
> > really care)
>
> Yes, I see three solutions:
>
> 1) ignore the proposal (but we must find a way to implement the same
> functionality without hacks!)
Easiest way.
> 2) change the Selector interface
-1
> 3) add another pipeline-aware routing sitemap component
I'm not sure it will be a good idea. It's more a gut feeling than
concrete concerns. I feel the control of the pipeline composition
will be put into content instead of the sitemap and thus giving dynamic
pipeline creation (which was abandoned from Cocoon 1).
> Tough decision indeed!
Sure.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Stefano Mazzocchi <st...@apache.org>.
giacomo wrote:
> In fact I don't think we can change the Selector interface as it is
> clearly stated what a Selector is and how it works (read: not a pipeline
> component). It doesn't mess with the SAX event in a pipeline (also for
> backwards compatability).
Yes, that's a good point, but the semantics looks so similar that might
be misleading... hmmm, I still don't know if this is a good idea or not.
> Maybe there needs to be other sematic in the sitemap to achieve what was
> requested (honestly I have not had the need for such things so I don't
> really care)
Yes, I see three solutions:
1) ignore the proposal (but we must find a way to implement the same
functionality without hacks!)
2) change the Selector interface
3) add another pipeline-aware routing sitemap component
Tough decision indeed!
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
> > > What do others think about this?
>
> The more I read about "pipeline selectors" the less I like them (DOM
> tree building, re-streaming, ...)...
I know, I know, I have the exact same impression myself :/
> However, don't you think that there is some overlap between these
> "sitemap selectors" and recently proposed "multiplexer"?
Hmmm...
> Using DOM
> implementation of it (it is possible to have one), you will be able to
> evaluate XPath expressions and choose one of the several execution paths
> - or pipelines (follow the tail of "RE: is cocoon symmetry a holy
> grail?" for details about this "multiplexer").
>
> What do you think about this?
yeah, that might solve the issue completely with elegance....yeah...
> > > C'mon, without input I won't change anything.
> >
> > In fact I don't think we can change the Selector interface as it is
> > clearly stated what a Selector is and how it works (read: not a
> pipeline
> > component). It doesn't mess with the SAX event in a pipeline (also for
> > backwards compatability).
>
> I agree with Giacomo: let's leave Selectors as they are, messing with
> old and well-known interface does not feel right.
Ok, let's leave them as they are.
Ignoring the issue isn't nice.
So I think the only way is to go with Vadim's proposal and implement
xpath-reacting multiplexers
Vadim, would you mind incorporating this in your proposal and get back
to us with a clear description of the picture?
I honestly admit I don't remember the full details and I might need a
recontextualization.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Pipe-aware Selectors
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: giacomo [mailto:giacomo@apache.org]
>
> On Wed, 6 Mar 2002, Stefano Mazzocchi wrote:
>
> > Michael Homeijer wrote:
> > >
> > > Hi Stefano,
> > >
> > > Could you please have another look at the solution described by
Bruno
> > > Dumon
> > > in the mailing list and comment on it.
> > > I'd really like to know what you think about it.
> > >
> > > It seperates the small incoming parts of data from the outgoing
flow,
> > > doesn't change any cocoon interfaces, and you will be able to
integrate
> > > results from processing incoming data into the pipeline again.
> >
> > Bruno wrote this example:
> >
> > <map:act type="FetchAndStoreXml" src="cocoon:/something">
> > <map:parameter name="storeAs" value="foo">
> > </map:act>
> > <map:select type="XPathSelector"
> > <map:parameter name="xmlName" value="foo">
> > <map:when test="/some/node = 'xyz'">
> > <map:redirect-to uri="somewhere">
> > </map:when>
> > <map:otherwise>
> > <map:generate type="XSLTGenerator" src="stylesheetsource">
> > <map:parameter name="xmlName" value="foo">
> > </map:generate>
> > <map:serialize/>
> > </map:otherwise>
> > </map:select>
> >
> > I have the feeling that this is a (admittedly brilliant!) hack.
> >
> > If we believe that Selectors should have access to the pipe flow, we
> > must change the interfaces, not create hacks with what is already
> > there... otherwise the system will be torn apart by these hacks (the
> > maintenance cost of the above code is huge since it's hard to
understand
> > what it does simply by looking at it!)
> > This is my perception.
> >
> > What do others think about this?
The more I read about "pipeline selectors" the less I like them (DOM
tree building, re-streaming, ...)...
However, don't you think that there is some overlap between these
"sitemap selectors" and recently proposed "multiplexer"? Using DOM
implementation of it (it is possible to have one), you will be able to
evaluate XPath expressions and choose one of the several execution paths
- or pipelines (follow the tail of "RE: is cocoon symmetry a holy
grail?" for details about this "multiplexer").
What do you think about this?
> > C'mon, without input I won't change anything.
>
> In fact I don't think we can change the Selector interface as it is
> clearly stated what a Selector is and how it works (read: not a
pipeline
> component). It doesn't mess with the SAX event in a pipeline (also for
> backwards compatability).
I agree with Giacomo: let's leave Selectors as they are, messing with
old and well-known interface does not feel right.
Vadim
> Maybe there needs to be other sematic in the sitemap to achieve what
was
> requested (honestly I have not had the need for such things so I don't
> really care)
>
> Giacomo
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by giacomo <gi...@apache.org>.
On Wed, 6 Mar 2002, Stefano Mazzocchi wrote:
> Michael Homeijer wrote:
> >
> > Hi Stefano,
> >
> > Could you please have another look at the solution described by Bruno Dumon
> > in the mailing list and comment on it.
> > I'd really like to know what you think about it.
> >
> > It seperates the small incoming parts of data from the outgoing flow,
> > doesn't change any cocoon interfaces, and you will be able to integrate
> > results from processing incoming data into the pipeline again.
>
> Bruno wrote this example:
>
> <map:act type="FetchAndStoreXml" src="cocoon:/something">
> <map:parameter name="storeAs" value="foo">
> </map:act>
> <map:select type="XPathSelector"
> <map:parameter name="xmlName" value="foo">
> <map:when test="/some/node = 'xyz'">
> <map:redirect-to uri="somewhere">
> </map:when>
> <map:otherwise>
> <map:generate type="XSLTGenerator" src="stylesheetsource">
> <map:parameter name="xmlName" value="foo">
> </map:generate>
> <map:serialize/>
> </map:otherwise>
> </map:select>
>
> I have the feeling that this is a (admittedly brilliant!) hack.
>
> If we believe that Selectors should have access to the pipe flow, we
> must change the interfaces, not create hacks with what is already
> there... otherwise the system will be torn apart by these hacks (the
> maintenance cost of the above code is huge since it's hard to understand
> what it does simply by looking at it!)
> This is my perception.
>
> What do others think about this?
>
> C'mon, without input I won't change anything.
In fact I don't think we can change the Selector interface as it is
clearly stated what a Selector is and how it works (read: not a pipeline
component). It doesn't mess with the SAX event in a pipeline (also for
backwards compatability).
Maybe there needs to be other sematic in the sitemap to achieve what was
requested (honestly I have not had the need for such things so I don't
really care)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Pipe-aware Selectors
Posted by Stefano Mazzocchi <st...@apache.org>.
Michael Homeijer wrote:
>
> Hi Stefano,
>
> Could you please have another look at the solution described by Bruno Dumon
> in the mailing list and comment on it.
> I'd really like to know what you think about it.
>
> It seperates the small incoming parts of data from the outgoing flow,
> doesn't change any cocoon interfaces, and you will be able to integrate
> results from processing incoming data into the pipeline again.
Bruno wrote this example:
<map:act type="FetchAndStoreXml" src="cocoon:/something">
<map:parameter name="storeAs" value="foo">
</map:act>
<map:select type="XPathSelector"
<map:parameter name="xmlName" value="foo">
<map:when test="/some/node = 'xyz'">
<map:redirect-to uri="somewhere">
</map:when>
<map:otherwise>
<map:generate type="XSLTGenerator" src="stylesheetsource">
<map:parameter name="xmlName" value="foo">
</map:generate>
<map:serialize/>
</map:otherwise>
</map:select>
I have the feeling that this is a (admittedly brilliant!) hack.
If we believe that Selectors should have access to the pipe flow, we
must change the interfaces, not create hacks with what is already
there... otherwise the system will be torn apart by these hacks (the
maintenance cost of the above code is huge since it's hard to understand
what it does simply by looking at it!)
This is my perception.
What do others think about this?
C'mon, without input I won't change anything.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org