RE: [RT] Input Pipelines (long)

[Michael Homeijer <M....@devote.nl>]

 

> Stefano Mazzocchi wrote:
>> Michael Homeijer wrote:
>> Hi,
>> 
>> I think your comment is right. It's not the (a)symmetry that's the
problem,
>> it's the "glue" that connects the input to the output thats missing or
>> implicitly available.
>
>Good, I'm glad we reached an agreement here.
>
>> Most of the time when using cocoon I use a solution/workaround of
having an
>> aggregation of an "input" pipeline (for instance writing a resource in
an
>> xml database) and the "output" pipeline (showing the new list of
resources
>> in the xml database). Most of the time the "logic" of the pipeline,
ie.
>> deciding if anything went wrong, ends up in xsl.
>> 
>> Because of the way map:handle-errors works (ie. you loose context
>> information etc.) I don't think it should be used to check application
>> logic/exceptions (for instance when a resource allready exists), but
only
>> system execeptions. 
>
>I agree.
>
>It comes to mind that it should be the flowscript layer to handle those 
>application-level exception out of an executed pipeline... or maybe 
>not... hmmm, what do you think about this?
>

Until this thread started I thought about the flowscript layer to be usefull
for "inter-request" flow (mainly continuations). Not for composing the logic
that handles a request. I'm still not sure... just a gut feeling. 
The application logic and exceptions I mentioned should be able to influence
the flow through the pipelines, not be mixed with the content of the
pipelines, and IMHO certainly not break it in the case of an application
exception.


>> Another way of implementing the input part (and mixing the flow part
in it)
>> is bij coding actions. This doesn't allways work out right as well.
Some
>> applications I build with cocoon contain far to many specific actions
>> handling input and flow, and actions are not very good at handling xml
/ sax
>> input.
>
>Yep.
>
>> A construction of "pipeline input - flow - pipeline output" should
solve
>> most of these cases, but I think the real "puzzle" will be how to fit
this
>> in with the allready existing "pipeline setup"/"pipeline execution
stages".
>
>Since you agreed that pipelines aren't necessarely asymmetric, why do 
>you need to specify 'input pipelines' above?
>

I only meant as a sample that the two pipelines should be logically
disconnected. Some examples I have seen transform and process input and in
the process mix output and generate the output html.
For instance 
"request generator" - "transform" - "write source" - "transform into output
(maybe by aggregation)" - "serialize".
This can be done, but mixes a lot of concerns, and how about a pipeline that
validates the input, writes to a source, mails a result to the user and
generates an output message, where the mail is optional and can be
configured.

>Wouldn't flow/pipeline and let you assemble them at need suffice?

I can not oversee the consequences of such a change. This would mean that a
pipeline consists of flow that glues together a number of
sub-pipelines/flows? Maybe.

My main problem is that in the current Cocoon version, a pipeline once setup
can hardly be influenced by some kind of control flow. And that mixing EJB
input / output, application exceptions and SAX makes things even more
complicated. Or should I say a challenge :-) 

I haven't seen a clean solution that made me jump in the air (which the
pipeline concept and the block concept did when I realised what they meant).
I'm hoping you have some more up your sleeve ;-)

Michael

>
>-- 
>Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: [RT] Input Pipelines (long)

[Stefano Mazzocchi <st...@apache.org>]

Michael Homeijer wrote:

> Until this thread started I thought about the flowscript layer to be usefull
> for "inter-request" flow (mainly continuations). Not for composing the logic
> that handles a request. 

If you think at input and output as two different stages of the same 
resource, then it makes sense to drive them thru the flow layer... 
instead of complicating the sitemap logic unnecessary.

> I'm still not sure... just a gut feeling. 

I'm not sure either :) but I feel that everything that makes the sitemap 
loose declarativity is actually conflicting with the flow layer.

> The application logic and exceptions I mentioned should be able to influence
> the flow through the pipelines, not be mixed with the content of the
> pipelines, and IMHO certainly not break it in the case of an application
> exception.

Yes, I see that. Do you believe that my proposals don't fit your 
requirements?

> I only meant as a sample that the two pipelines should be logically
> disconnected. Some examples I have seen transform and process input and in
> the process mix output and generate the output html.
> For instance 
> "request generator" - "transform" - "write source" - "transform into output
> (maybe by aggregation)" - "serialize".
> This can be done, but mixes a lot of concerns, and how about a pipeline that
> validates the input, writes to a source, mails a result to the user and
> generates an output message, where the mail is optional and can be
> configured.
> 
> 
>>Wouldn't flow/pipeline and let you assemble them at need suffice?
> 
> 
> I can not oversee the consequences of such a change. This would mean that a
> pipeline consists of flow that glues together a number of
> sub-pipelines/flows? Maybe.
> 
> My main problem is that in the current Cocoon version, a pipeline once setup
> can hardly be influenced by some kind of control flow. 

Yes, we have identified this weak architectural point in the other 
thread about input pipelines and I'm all for solving it... but I still 
have to figure out what this means and hot it impacts the whole picture.

> And that mixing EJB
> input / output, application exceptions and SAX makes things even more
> complicated. Or should I say a challenge :-) 
> 
> I haven't seen a clean solution that made me jump in the air (which the
> pipeline concept and the block concept did when I realised what they meant).
> I'm hoping you have some more up your sleeve ;-)

Hey, don't challenge me, boy :)

No, serious, I don't have a magic clearcut solution to the problem... 
but I have a gut feeling that it's better to add procedural logic to the 
flow on how to use the declarative facilities provided by the sitemap, 
than the other way around.

but I think i need to get my hands dirty and do something to see which 
method fits best.

-- 
Stefano Mazzocchi                               <st...@apache.org>
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org