After a long silence, Daniel fights back :-)
:)
On Feb 25, 2004, at 10:49, Daniel Fagerstrom wrote:
[snip very good summary]
To sumarize: I think that we could make Cocoon considerably easier to use for (web)apps and increase reuse of components by using the XML-adaptor and pipes and filter pattern for input as well.
There is, admittedly, a perception that cocoon is still somewhat unbalanced between input and output. CForms and flowscript show nice ways (easier than many other web technologies!) to deal with data round-tripping, but Daniel believes that we should do more, balancing the entire architecture so that what we can do with output, we can do with input.
Now, I agree.
I've been opposing the use of a common input adaptation stage because I thought it was bad from a performance perspective, but, I now believe that it's a very stupid point: early optimization is the root of all evil, especially in architectural design.
[doesn't mean that you don't think about performance when you architect, but there are many levels of design]
So, I'm happily removing the roadblock because I think we are reaching a point where this unbalance is hurting us (and potentially limiting the use of input to go thru cforms, which might be too much)
Cool!
[can we stop using the term 'woody' at least in RTs? this makes things easier for people reading archives a few years from now]
I used the term "Woody" when I talked about things that I hope that we will replace when we move to CForms ;) The things that Bruno described in his post http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104920680728548&w=2 as:
BTW, not using XML, XML validation, and XPath expressions as request parameter names is a conscious choice, so what I'm describing here is quite orthogonal to XMLForm, and leaning more towards FormValidatorAction.
Ok, Daniel, the ball is in your court: tell us explicitly what you would propose we change in the sitemap/FOM/cforms, if anything.
Ok, I will try to give an overview of my change proposals in prority order:
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).
There has been some discussions about what kind of utility components we should add to flowscripts. I think the above description give some usefull guidelines for that. We need component that makes it easy to handle DOM, and especially a typed DOM implementation (as I described in my previous post). We need components that adapt from various formats to DOM and from DOM to various output formats. Examples of this is: CForms adapts structured request params to typed DOM and use typed DOM to generate forms. We need a bidirectional mapping between DOM and Java data structures, (this can be based on the ideas from the Woody binding framework). A bidirectional mapping between XML and a relational DB would be usefull. Components that store and read XML data from repositories would be usefull as well.
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.
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 http://marc.theaimsgroup.com/?t=104029502400001&r=1&w=2 and http://marc.theaimsgroup.com/?t=104134298900002&r=1&w=2.
New sitemap constructions? --------------------------
In the input pipeline threads: http://marc.theaimsgroup.com/?t=104008605100003&r=1&w=2 and http://marc.theaimsgroup.com/?t=104193709500001&r=1&w=2 a year ago. I argued for some new sitemap components. The idea was mainly to introduce a component that behaves as a serializer, let us call it store, with two differences: 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
part of the pipeline that take care of the user input and store it somewhere. After that you can have a selector that reacts on the stored data or maybe on some meta data signaling the pipeline state (success or failure). And after that an ordinary publishing pipeline:
generator -> transformer* -> serializer
where the generator typically reads from the stored data. 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 http://marc.theaimsgroup.com/?t=106864448500002&r=1&w=2 actually was a quite usefull idea. So based on that I would like to allow a "flowscript action" between the input and the output pipeline. In the flowscript action a flowscript function is called with parameters as in an ordinary flowscript call, and the return value from the function is stored in the flow attribute. The use of continuations would be prohibited to avoid strange behaviours.
So a pipeline for input handling could look like:
g -> t* -> store -> act -> [select] -> g -> t* -> s.
I think the proposed constructions would increase sitemap readabillity for such use cases of flowscripts when no page multi page flow are used. And that it would be a nice replacement of the current use of actions. But all of this can already be done by using flowscripts and processPipeline To[...] constructs, (although the readabillity might not be so good). So I don't find such extensions nearly as important as I found them one year ago :)
/Daniel
