cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [ANN] New version of XMLForm released
Date Wed, 02 Apr 2003 10:47:52 GMT
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.


Mime
View raw message