cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guido Casper <>
Subject Re: [RT] Cocoon Input Model
Date Sun, 29 Feb 2004 10:34:59 GMT
Steve Krulewitz wrote:
> 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 
> - 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.

And I believe most of the functionality Daniel is envisioning (IIUC) can
be achieved today by:

So you can try such kind of architecture to see how it works out.


> 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

View raw message