Nicola Ken Barozzi wrote:
>
> From: "Stefano Mazzocchi" <[EMAIL PROTECTED]>
>
> > 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.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
