Daniel Fagerstrom wrote: > > Stefano Mazzocchi wrote: > > > > 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.
This is true. > 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. Yes, I clearly see your point. > 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. Agreed. > 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. I think you expressed a very valid point of the need for pipe-based selection. I have two concerns: 1) a pipe-selector is really a selector or is it something else? [translated operationally: should we come up with another interface?] 2) how does this impact performance? how does this impact caching? [the first impacts the system usage, the second the interface of Selectors or PipeSelectors] anybody else? -- 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]
