> From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]]
<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
and
> 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
to
> 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
you
> with. I got the same functionality in my code using Avalon and Java.
So
> I wrote a simple transformer that did all this, save where I wanted
with
> 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
time
> to make it shorter.
>
> Which can be translated with: I'm adding more sitemap semantics,
because
> I lacked the time (will?) to make it shorter and force you in
directions
> 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 -
Explanation:
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...
Vadim
> --
> 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]
