cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Cocoon Input Model
Date Wed, 25 Feb 2004 21:53:14 GMT
Stefano Mazzocchi wrote:

> 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



Mime
View raw message