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.
What you correctly point out, is that the Generation phase not get the source, but just transform it to SAX.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>
<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.
Pipelines can already call one another.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.
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 :-)
Also this seems interesting.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.
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.
Cocoon already does this, no?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.
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 [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
