* Daniel Fagerstrom <[EMAIL PROTECTED]> [2004-02-25 21:53]: > 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). Might flowscript become less important if input pipelines where brought into play? 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. 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. > 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. 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. > 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. > 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? > -------------------------- > 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. > 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? > So a pipeline for input handling could look like: > g -> t* -> store -> act -> [select] -> g -> t* -> s. Something like that indeed. -- Alan / [EMAIL PROTECTED] / http://engrm.com/ aim/yim: alanengrm - icq: 228631855 - msn: [EMAIL PROTECTED]
