cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: [RT] Input Pipelines (long)
Date Tue, 17 Dec 2002 13:46:39 GMT

Daniel Fagerstrom wrote:
[...]

Cocoon is symmetric, if you see it as it really is, a system that 
transforms a Request in a Response.

The problem arises in the way we have defined the request and the 
response: The Request is a URL, the response is a Stream.

So actually Cocoon transforms URIs in a stream.

The sitemap is the system that demultiplexes URIs by associating them 
with actual source of the data. This makes cocoon richer than a system 
that just hands an entity to transform: Cocoon uses indirect references 
(URLs) instead.

The Stream as an input is a specialization, so I can say in the request 
to get stuff from the stream.

More on this later.

> In a sitemap an input pipeline could be used e.g. for implementing a
> web service:
> 
> <match pattern="myservice">
>   <generate type="xml">
>     <parameter name="scheme" value="myInputFormat.scm"/>
>   </generate>
>   <transform type="xsl" src="myInputFormat2MyStorageFormat.xsl"/>
>   <serialize type="dom-session" non-terminating="true">
>     <parameter name="dom-name" value="input"/>
>   </serialize>
>   <select type="pipeline-state">
>     <when test="success">
>       <act type="my-business-logic"/>
>       <generate type="xsp" src="collectTheResult.xsp"/>
>       <serialize type="xml"/>
>     </when>
>     <when test="non-valid">
>       <!-- produce an error document -->
>     </when>
>   </select>
> </match>

What you correctly point out, is that the Generation phase not get the 
source, but just transform it to SAX.

  <match pattern="myservice">
    <generate type="xml">
      <parameter name="scheme" value="myInputFormat.scm"/>
    </generate>
    <transform type="xsl" src="myInputFormat2MyStorageFormat.xsl"/>
    <serialize type="dom-session" non-terminating="true">
      <parameter name="dom-name" value="input"/>
    </serialize>
    <select type="pipeline-state">
      <when test="success">
        <act type="my-business-logic"/>
        <generate type="xsp" src="collectTheResult.xsp"/>
        <serialize type="xml"/>
      </when>
      <when test="non-valid">
        <!-- produce an error document -->
      </when>
    </select>
  </match>

But IMHO this has a deficiency of fixing the source from the input.
Think about having good Source Protocols.

We could write:

  <match pattern="myservice">
    <generate type="xml" src="inputstream:myInputFormat.scm"/>
    ...
  </match>

This can easily make all my Generators able to work with the new system 
right away.

> Here we have first an input pipeline that reads and validates xml
> input, transforms it to some appropriate format and store the result
> as a dom-tree in a session attribute. A serializer normally means that
> the pipeline should be executed and thereafter an exit from the
> sitemap. I used the attribute non-terminating="true", to mark that
> the input pipeline should be executed but that there is more to do in
> the sitemap afterwards.

Pipelines can already call one another.
We add the serializer at the end, but it's basically skipped, thus 
making your pipeline example.

I would think that with the blocks discussion there has been some 
advancement on the definition of pipeline fragments.
I didn't follow it closely though, anyone care to comment?

> After the input pipeline there is a selector that select the output
> pipeline depending of if the input pipeline succeed or not. This use
> of selection have some relation to the discussion about pipe-aware
> selection (see [3] and the references therein). It would solve at
> least my main use cases for pipe-aware selection, without having its
> drawbacks: Stefano considered pipe-aware selection mix of concern,
> selection should be based on meta data (pipeline state) rather than on
> data (pipeline content). There were also some people who didn't like
> my use of buffering of all input to the pipe-aware selector. IMO the
> use of selectors above solves booth of these issues.

I don't see this. Can you please expand here?

[...]
> In Flowscripts
> --------------
> 
> IIRC the discussion and examples of input for flowscripts this far has
> mainly dealed with request parameter based input. If we want to use
> flowscripts for describing e.g. web service flow, more advanced input
> handling is needed. IMO it would be an excelent SOC to use output
> pipelines for the presentation of the data used in the system, input
> pipelines for going from input to system data, java objects (or some
> other programming language) for describing business logic working on
> the data within the system, and flowscripts for connecting all this in
> an appropriate temporal order.

Hmmm, this seems like a compelling use case.
Could you please add a concrete use-case/example for this?
Thanks :-)

> For Reuseability Between Blocks
> -------------------------------
> 
> There have been some discussions about how to reuse functionality
> between blocks in Cocoon (see the threads [1] and [2] for
> background). IMO (cf. my post in the thread [1]), a natural way of
> exporting pipeline functionality is by extending the cocoon pseudo
> protocol, so that it accepts input as well as produces output. The
> protocol should also be extended so that input as well as output can
> be any octet stream, not just xml.
> 
> If we extend generators so that their input can be set by the
> environment (as proposed in the discussion about input pipelines), we
> have what is needed for creating a writable cocoon protocol. The web
> service example in the section "In Sitemaps" could also be used as an
> internal service, exported from a block.
> 
> Booth input and output for the extended cocoon protocol can be booth
> xml and non-xml, this give us 4 cases:
> 
> xml input, xml output: could be used from a "pipeline"-transformer,
> the input to the transformer is redirected to the protocol and the
> output from the protocol is redirected to the output of the
> transformer.
> 
> non-xml input, xml output: could be used from a generator.
> 
> xml input, non-xml output: could be used from a serializer.
> 
> non-xml input, non-xml output: could be used from a reader if the
> input is ignored, from a "writer" if the output is ignored and from a
> "reader-writer", if booth are used.
> 
> Generators that accepts xml should of course also accept sax-events
> for efficiency reasons, and serializer that produces xml should of the
> same reason also be able to produce sax-events.

Also this seems interesting.

Please add concrete examples here to, possibly applied to blocks.
I know it's hard, but it would really help.

It seems that what you propose Cocoon already mostly has, but it's more 
the use-case and some minor additions that have to be put forward.

> Conclusion
> ----------
> 
> The ability to handle structured input (e.g. xml) in a convenient way,
> will probably be an important requirement on webapp frameworks in the
> near future.
> 
> By removing the asymmetry between generators and serializers, by letting
> the input of a generator be set by the context and the output of a
> serializer be set from the sitemap, Cocoon could IMO be as good in
> handling input as it is today in producing output.

Cocoon already does this, no?
Can't we use the cocoon:// protocol to get the results of a pipeline 
from another one? What would change?

> This would also make it possible to introduce a writable as well as
> readable Cocoon pseudo protocol, that would be a good way to export
> functionality from blocks.

Please expand on this.

> There are of course many open questions, e.g. how to implement those
> ideas without introducing to much back incompability.

If we see the use cases, it would be much easier.

Your ideas are interesting, and I see too this asymmetry.
If you expand in the aboive areas, it would be really of help for me.

Thanks :-)

> 
> References
> ----------
> 
> [1] [RT] Using pipeline as sitemap components (long)
> http://marc.theaimsgroup.com/?t=103787330400001&r=1&w=2
> 
> [2] [RT] reconsidering pipeline semantics
> http://marc.theaimsgroup.com/?t=102562575200001&r=2&w=2
> 
> [3] [Contribution] Pipe-aware selection
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=101735848009654&w=2


-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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


Mime
View raw message