ivelin wrote:
I am proposing to move XMLForm to a block, following the recent suggestions
by Torsten and Vadim.
Very similar to
http://cvs.apache.org/viewcvs.cgi/cocoon-2.1/src/blocks/chaperon/
The lib directory will include the jar file with all the files shared
between the standalone and the cocoon module.
The java directory will include the Action and Transformer adapters.
Samples will remain mostly unchanged, except for the namespace and tag names
upgrade.

If you are volunteering to do the job, you get my +1 (I'm a lazy butt, you know :)


As a related note, any cocoon commiter can have immediate write access to
the XMLForm CVS @ SF.net. Just ask.

More seriously, the above vote is really a +1 and for a few reasons:


During the last year of consultancies, I found out that several people identified XMLForm as the possible way to turn cocoon into better webapp-capable system.

That kept coming out was: "XMLForm vs. Flow: which one should I invest on?"

But it's like comparing apples and oranges. In fact, Chris has shown pretty evidently with his work on the petstore that the flow is an underlying system (more comparable to actions, for that matter) and several views and controllers can be plugged on top.

XSP,JXPath,Jexl,Velocity,XSLT are all potential "views", template engines for the data passed by the underlying controllers.

Note that the sitemap is not MVC, but something more: control is further separated into smaller concerns:

 - URI-space control (sitemap)
 - flow-logic control (flow/actions)
 - data-logic control (???)
 - business-logic control (your objects)

the "data-logic control" answers questions like

 - how do I represent a form in memory?
 - how do I validate it?
 - how do I persistently store it?

and include all that 'somewhat-business-logic' that is sooooo common between webapps that should be factored out and provided directly by cocoon (as struts, somewhat, does).

And one of the providers for such mechanisms can be the XMLForm block.

But I'm more than happy to see XMLForm being factored out because:

1) this removes the wrong marketing perception that XMLForm is *the* solution for data-logic control.

2) allows people to experiment different approaches (XForm-based or not) with the same level of confidence.

Comments?

Stefano.



Reply via email to