cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Krulewitz <>
Subject Re: [RT] Cocoon Input Model
Date Sat, 28 Feb 2004 16:10:40 GMT
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.  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:generate type="httpdeserializer">
       <map:parameter name="query" value="customerid,orderid"/>
    <map:transform type="sql"/>
    <map:serialize type="object"/>


<map:pipeline match="/orders">
   <map:input name="orders"/>
   <map:generate type="jx"/>
   <map:transform "orders.xslt"/>


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?


View raw message