cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <>
Subject Re: [RT] Cocoon Input Model
Date Fri, 05 Mar 2004 18:03:04 GMT
Alan wrote:
> * Daniel Fagerstrom <> [2004-02-25 21:53]:
>>XML centric view on input
>>The most important part is not a code change but rather a design 
>>principle: Input handling is controlled from flowscripts, the flowscript 
>>typically adapt various input sources to XML (DOM), possibly by using 
>>pipelines described in the sitemap, it can validate the XML wrt to some 
>>schema, and it adapts XML to various output and storage formats, 
>>(possibly by using a pipeline). (If you are extremely unhappy about 
>>flowscripts, you can replace the mentioned flowscripts with your 
>>favourite script or programming language ;-) IMHO we should focus on 
>>flowscripts however).
> Might flowscript become less important if input pipelines where brought into
>     play?

Not necesarily, it is more a design pattern that can be implemented e.g. 
in terms of processPipelineTo[...]

>     You might have a validator element in the sitemap. If the document
>     validates accoriding to the validator the pipeline continues, if it fails,
>     an error pipeline executes that has validator error message output as a
>     starting point.

You don't need a new kind of sitemap component for that. You can 
implement the validator as a transformer, that throws some kind of 
InvalidXMLException when it fails, then you can register this exception 
in the configuration of the exception selector, and produce the 
appropriate error message output in the map:handle-error section.

>     Once data is valid, you would then multiplex it into the various storage
>     devices, or XML consumers.
>     Once all the data is consumed, you fire off your output pipeline.
> What little flow script I've played with, I'm usually just messing with
>     request parameters. If I could express this as a sitemap input pipeline, I
>     wouldn't bother.

You use them for connecting to back end and for multi page flow logic also.

>>A bidirectional mapping between XML and a relational DB would be usefull.
> I offered a unidirectional mapping in my previous post. Now that I think of
>     it, that is the big difference between what I have in mind and what I
>     normally see.
>     Data comes out of a RDBMS easily using SQL, a generator turns that into
>     XML, you then transform it to output. I've never seen the need for
>     bi-directional because for one direction at least, there is a perfect way
>     to preform the mapping. Express your desires in SQL. It is *always* a
>     table and therefore has an obvious representation in XML.
>     A bi-directional mapping will always produce a table as output anyway.

No, if you have "deeper" XML document you need to map it to several 
tables and relations between them.

>     The trick is not getting the information out. Most RDBMS are SQL
>     databases and SQL is a *query* lanaguge.
>     Most people try to describe a bi-directional mapping and expect some
>     reward for this touble in (output) query generation. I'd rather describe
>     the database schema in an XML document, that is describe how I want the
>     data to go into the database, not how the database maps to an XML
>     document. There is a difference here.

A common situation in our applications, and I would assume others, is 
that we have lots of customer data in an RDBMS and that we want to store 
some user input from our webapp as well. We always transform the user 
input to XML, so it would of course be much more convinient to store the 
user input in an XMLDB. But then we need to combine the user input with 
what allready is in the RDBMS, so it would not work well to store it in 
another DB. We therefore need a way to store XML in a RDBMS. Currently 
we do that by writting one XML->RDBMS mapping and one RDBMS->XML for 
each XML schema. It would be better to combine it in one mapping.

>>Components that store and read XML data from repositories would be usefull
>>as well.
> MomentoSource!
>>CForms should use typed DOM as "form model"
>>I also believe that making CForms use typed XML as data storage is 
>>important. This obviously require some changes, among other things the 
>>widget objects need to be split into a control part and a storage part, 
>>XML data types need support. I will return with a detailed proposal in 
>>the near future (hopefully ;)). I also hope to get some feedback from 
>>the people involved in CForms development.
> Typed DOM? Confused. Concerned that it might become to grand a scheme. 
>     I much perfer pipelines to fiddling with nodes.

See answer to Guido

>>Access to the input stream in all environments?
>>We still have the open question about in which environment the input 
>>stream should be available.
>>See and 
>>New sitemap constructions?
>>It can have a destination parameter where you can use a 
>>modifyable source, and it does not provoke a return from the sitemap. By 
>>using this you can have an input:
>> generator -> transformer* -> store
> Good name.
>     I see this happening:
>         ! = exception
>     generator -> validator -> muliplexer -> pipeline (success)
>                                   |
>                      !            +-> transformer -> store (session document)
>                      |            |
>                      |            +-> transformer -> store (Momento)
>                      |            |
>                      |            +-> transformer -> store (LDAP)
>                      |            |
>                      |            +-> transformer -> store
>                      |                          (photo album web service)
>                      |              
>                      + ->         ! -> pipeline (error)
>     A validator is a branch tool like select. If the validator returns true,
>     we conditue if it returns false, we fire an error pipeline, or error
>     branch under the validator element.
>     A muliplexer is the oppposite of an aggregator.

We had discussions about multiplexors earlier at cocoon-dev, don't 
remember the name of the threads or the conclussions though. What is you 
use case for them?

>>After having thought about it I think that Andrzej Jan Taramina:s "missuse"
>>of flowscripts discussed in the "[RT] Is flowscripts polluting sitemap 
>>readabillity?" thread...
> I'm going to read up on this. Flowscript is cool and continuations are cool.
>     There is a lot going on there I've yet to study.
>     They do seem to be quite apart from the sitemap, though. It would be nice
>     to see them better integerate with the site map so that a site map read is
>     easier. (I'll note once again that publishing with Cocoon is easier to
>     learn.)
>     But then, if we manage to store everything at each form post in the
>     appropriate place, are contniuations necessary? 

I would prefer not needing to use continuation when I use the flow 
script as an action. For multi page flow you need continuations.

>>So a pipeline for input handling could look like:
>>g -> t* -> store -> act -> [select] -> g -> t* -> s.
> Something like that indeed.


View raw message