Nicola Ken Barozzi wrote:
>
> From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
>
> > My impression is that pipe-aware selection is 'forcing' metadata to pass
> > 'thru' the pipeline while it doesn't really make sense to do so.
> >
> > So, IMO, there must be some transformers that obtain the required
> > selection information from the pipeline, place it somewhere else
> > (probably someplace in the object model) and have the selectors look at
> > those 'parallel signals' without having to mess with the pipeline.
>
> Bud don't Selectors get to run *before* Transformers.
Not necessarely, but I get your point.
> This is the whole point it seems.
> It's not a matter of how, but when.
ok, point taken (see below)
> Selectors can run after Transformers only if another pipeline is called, and
> this will basically force you to use the flow pipeline for this, since in
> fact it's flow we're talking about.
>
> As I see it, Matchers, Selectors and stuff can easily be put all in the flow
> part, but this makes Cocoon too "procedural".
>
> An easy tip: if you serve web pages, use the pipeline only. If you need to
> make complex decisions and procedures on the flow, use the flowmap.
I wouldn't venture to state design patterns *before* the flowmap and the
sitemap get integrated.
Ovidiu, how long do you think it would take to have the two live
together?
> > So, I restate my -1 on pipe-aware selection and I propose the creation
> > of a 'parallel transport layer' between components that is based on
> > objects and not SAX events.
>
> Could you elaborate more on this?
>
> I think it's something like having a request object, but seen as a parallel
> pipeline.
>
> I'm +1000 on this, since it finally fullfilles the original intention we had
> with Cocoon2 pre-alpha to have a parallel metadata pipeline, where there are
> also notifications.
>
> Gee, it seems that you saw right before needing it! :-O
No, careful. The wild idea of a meta-pipeline had to deal with
debugging, error handling and profiling. It was not meant to be another
'transport' of information between components.
We might have this in place already (I don't really know the last
changes in such a great detail), but it would be enough to have
components 'Contextualizable' with a request-living context where
components read and write.
Now, if a component has the ability to write something on the request
context, a selector has the ability to select based on this variable
read from the context.
So, if we have an error in a transformer that writes on a database, we
don't have to 'write this information inside the pipeline' in order for
a subsequent selector to get it and behave consequently.
I'm perfectly aware of the fact that components must pass information
one another, but, why in hell should they use something so ackword as
SAX events to write and XPath queries to read when they can simply do an
hashtable lookup?
Do you pipe-aware selector fans see my point?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
