cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <>
Subject RE: is cocoon symmetry a holy grail?
Date Thu, 14 Feb 2002 05:57:59 GMT
> From: Stefano Mazzocchi []

<OT> I like the subject :) </OT>
> This is explicitly provocative, but this is very important so here it
> goes:
> suppose we have implemented what Vadim proposed in the his earlier
> thread: so 'separators' and a way to instruct the pipelines to direct
> the serializers' output to different output streams.
> Suppose you give this to a Cocoon user.
> Oh, he loves it. Elegant, simple, very straightforward.

Thanks, I will take this as a compliment :)

> He uses it like this
>                   pipeline1 ---> disk
>                 /
>  POST request -*
>                 \
>                   pipeline2 ---> response
> It looks so nice... but, wait, how do I know there was an error saving
> the file? or sending an email? or printing the PDF on the printer? or
> stream a request to nuke the alien insects orbiting around jupiter?

There are some options:
1. Throw an exception. Remember, pipelines are processed in a serialized
fashion, in one thread. You are in charge to set the order of execution.
2. Log an error into a log file
3. SNMP trap
4. email to sysadmin
5. <here can be your option>

(2, 3 are very popular in the place were I'm currently employed)

> Hmmmm, I have to stop the pipeline2 until the pipeline1 has finished
> returned me an error code.

This is not right 'cause see (1) above. Exception thrown in sub-pipeline
will have same effect as exception thrown in regular Cocoon pipeline. I
see no difference.

> Gosh, I have to implement a way to pass things... a shared memory?

You have:
1. Request attributes
2. Session attributes
at your disposal. May be even global attributes (analogue to
"application" scope in JSP - do we have it in Cocoon?) I did not put
objectModel as third option because there is no consensus on how can it
be used.

> ah, no should I implement Contextualizable?
> hmmm....
> oh, but look: what if I do something like
>  request -> pipeline -> response
>               | ^
>               v |
>               disk
> Now I did save the file and I know the the error right there.

That's another approach and is still valid and *very* useful in some
(other) cases, and I would be first one against prohibiting this. I vote
for flexibility (you always can stop me when it grows into syndrome ;))
and extensibility, which we have in Cocoon now: every type of person can
find his "sweet spot" in Cocoon, be it XSP and logicsheets, or custom
made transformers, or anything else.

> what? you said it was more complex because the serializer was easier
> use?
> Bah, I implemented a "serializing" component that gave me that service
> in a few calls, the cocoon serializers are simply sitemap components
> wrapping this other avalon component. A sitemap-semantic adaptor, if
> with. I got the same functionality in my code using Avalon and Java.
> I wrote a simple transformer that did all this, save where I wanted
> a few lines of code and that was it.
> .....
> I'm starting to think this 'separator' concept is going to be a
> nightmare for users, also because it seems to promising.

Might be, hence this is an [RT] and the point of the discussion is to
choose the right approach (and one of them is - leave everything as it
is). But as you sad, it is promising, that's why I think it's important
to discuss and extract usefulness leaving nightmare were it belongs.

> But can it stand the apparent elegance expectation?
> remember Pascal: I'm writing you a long letter because I lacked the
> to make it shorter.
> Which can be translated with: I'm adding more sitemap semantics,
> I lacked the time (will?) to make it shorter and force you in
> that we know are better for you down the road.
> Comments?

One more comment on this. If the lack of the response is the only thing
stopping this idea to be reality...

I have another one, it provides different functionality but it features
similar approach. As I don't have a name for this (multiplexer?), here
is the diagram:

                  - pipeline1 -
                 /              \
request -> A -> X - pipeline2 - X -> C -> response
                 \              /
                  - pipelineN -

1. Request goes in
2. Pipeline is being constructed from A, X, C
3. SAX events passed from the A to X, where they are dispatched (same as
separator) to several other pipelines
4. SAX events passed from these events reassembled into the one SAX
stream by the same instance of X component
5. Result passed down the original pipeline to the C
6. C spits out the response

Don't answer "hey, you can do this with content aggregator" - it is not
true, this is a different thing.

Waiting for comments...

> --
> Stefano Mazzocchi      One must still have chaos in oneself to be
>                           able to give birth to a dancing star.
> <>                             Friedrich Nietzsche
> --------------------------------------------------------------------

To unsubscribe, e-mail:
For additional commands, email:

View raw message