I agree that more sophisticated input handing would make general web applications much easier to write in Cocoon... here are some more random thoughts on the subject:
Input can come from many sources:
- http query string - http post stream - http cookie - user session object (from disk? database?) - raw socket? - any of the above interpreted as XML
The purpose of input handing should be to massage and validate data sent over HTTP to something that you can confidently hand over to a strongly typed business object. Here are some of the things that, in my experience, this usually amounts to:
- required value checking
- datatype checking and casting (is it a date? then make it a j.u.Date)
- min/max string length or value checking
- value formatting
- database value checking (is that state_id the user sent really in my table of states?)
- hash check of fields (to verify the data has not been modified over the round trip -- does this hash match the hash of these other fields?)
- converting the value of a single field, or the entire input stream, to XML
- decrypting of a single field into multiple fields (and then apply the above to the decrypted fields)
This, of course, sounds a whole lot like forms processing, and I don't see any reason why it shouldn't be handled by cforms.
Exactly. And I believe most of the functionality Daniel is envisioning (IIUC) can be achieved today by: processPipelineToXY("PipelineStartingWithSpecialWoodyGenerator");
So you can try such kind of architecture to see how it works out.
Guido
The input "pipeline" would look something like:
1. A deserializer component is used to convert the raw input into XML. A deserializer component would be mated to each type of input -- for example, the HTTPDeserializer would turn HTTP headers into a simple XML document (or just selected parts of the header based on a parameter).
2. More than one deserializer could be employed for a particular request -- the result would be aggregated into a single document.
3. cforms validation
4. transformations**
5. either make result XML available as input to a pipeline (as a generator) or bind to a Java object for use in an action/flow/jxtemplate.
** Including transformation steps in this "pipeline" might seem like overkill, however I would find it very useful. If the user sends an ID, a SQLTransformer here could be used to convert that ID into more information from the database. This is _not_ the same as using a SQLTransformer in the output pipeline since we want to be able to access this data from flow through the Java object produced in step 5.
Now where does this belong in the sitemap? I think these input pipelines should be separate from the main pipelines, and be called similar to the way actions do:
<map:input-pipeline name="orders"> <map:aggregate> <map:generate type="httpdeserializer"> <map:parameter name="query" value="customerid,orderid"/> </map:generate> <map:transform type="sql"/> <map:serialize type="object"/> </map:input-pipeline>
...
<map:pipeline match="/orders"> <map:input name="orders"/> <map:generate type="jx"/> <map:transform "orders.xslt"/> <map:serialize/> </map:pipleline>
~~~~~~~~~~
Of course, this also opens a lot of questions on how cforms is integrated into cocoon... and where do "input" pipelines end and where "output" pipelines begin?
cheers, -steve
