Stefano Mazzocchi wrote: > Michael Homeijer wrote: <snip/> > > In the current situation, the pipelines parts for incoming data and the > > parts for outgoing data are executed without having a > possibility to change > > the outgoing pipeline based on the data returned from the incoming part. > > Again, please, give us a clear example on this. <snip/> > My irrational perception says that having selectors react on what flows > into the pipes mixes concerns: in fact, selectors should 'route' the > content of the pipeline, while the pipelines content should 'passively' > be routed around by the external machinery. > > What do others think about this?
IMHO, introducing xml based selectors would be a _major_ step in making Cocoon as good for input handling as for output handling. Why is that? I think an important asymetry between input and output handling in Cocoon is that output handling is about data structures: XML, while input is mainly handled in terms of simple data types, like strings in request headers and parameters. Matchers, selctors and actions provide good mechanisms for choosing output pipline based on such simple input. While an XML document describes data as well as its interrelationships, the request parameters does not include any information about relations at all, this structure must be coded in the input handling code instead. No wonder that it is hard to write reusable input handling components. Maybe we would prefer to have structured data - XML in the request-body, as for XForms, SOAP or WebDAV, or any input that would be easily transformed to XML. Then, things become more complicated: The "natural" place for XML is a pipeline so that we can reuse all the existing pipeline components and especially so that e.g. xslt can be used to modify the input. Unfortunally this is currently not a good idea becase, as soon as one have started a pipeline it is not possible to do any conditional composition of the pipeline anymore. And conditional processing is realy needed when input is handled. First: it is a good idea to validate input data. One possiblity is to have a "ValidationTransformer" that, based on a schema, annotates the input elements with error data. If the input have field errors, we probably want to resend the partially filled in input form with error messages otherwise the data should continue to the next step in the pipeline. This kind of validation handling could easily be implemented with an xml based selector. See: http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100745068703675&w=2 http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=100750124213953&w=2 for more details about xml input validation. After having validated our data we might want to use a transformer with side effects for storing it or for using it as input to some business logic. Especially with the recent introduction of the WriteableSourceTransformer, this seem like an important scenario. But transformers with side effects can fail, and in this case they should generate an (XML) output that tells what went wrong, and as different responses to the user for success and failure seem appropriate, we have another use case for the xml based selector. Time for an example: <map:match pattern="userDataInsert.xml"> <map:generate type="stream"/> <map:transform src="userData.xsd" type="validator"/> <map:pipe-selector type="xpath"> <map:when test="/*/@fatal-error"> <map:transform src="structureErrors.xsl"/> </map:when> <map:when test="/*/@field-error"> <map:transform src="userDataForm.xsl"/> </map:when> <map:otherwise> <map:transform type="file-writer" dest="userData.xml"/> <map:pipe-selector type="xpath"> <map:when test="/result/file-writen='true'"> <map:transform src="reportInsertResult.xsl"/> </map:when> <map:otherwise> <map:transform src="reportInsertError.xsl"/> </map:otherwise> </map:pipe-selector> </map:otherwise> </map:pipe-selector> <map:serialize/> </map:match> The "pipe-selector" must collect all input XML in e.g. a DOM-tree before it can make its chooice. The "validator" anotates the input data with attributes that describe the result of the validation. The "file-writer" is suposed to describe the result of the write in its output. The functionality in the example could be implemented in current Cocoon by e.g. placing all flow control logic in an xslt-transformer, but in that case the sitemap does not say much about what happens in the aplication and reuse is mainly based on import of xslt documents. Another possibility is to prepare for all conditional processing by processing XML-data in an action set, but if pipeline processing is needed, one have to write actions that read and write dom-trees in the request attributes. This means that we will need action-variants of several of the existing transformers - not that elegant. There has been some discusions about the need for "input pipelines" in Cocoon, IIRC someone described the idea as: an input pipeline, followed of an action set followed of an output pipeline. I think this idea is fairly related to xml based selection. As there IMHO is a real need for several chooice points in a pipeline (as in the example), I prefer xml based selection. To conclude: I belive that xml based selection together with transformers with side effects can considerably reduce the need for actions and that it would make it much easier to write Cocoon aplications that takes xml input. What do you think? /Daniel Fagerstrom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
