cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Modernizing CForms
Date Mon, 19 Mar 2007 09:30:57 GMT
Daniel Fagerstrom wrote:

> I don't propose that we should throw out the current Forms framework.
> What I do propose is that it could be improved so that it would
> require less work to use and so that it would support AJAX+REST style
> webapps better.
> Don't repeat yourself
> =====================
> As an alternative to using XML configurations for form definition and
> binding both the form definition object and the binding object could
> be configured from annotations in the model bean. With some decent set
> of conventions, people who follow the conventions would be able to
> connect forms to the business model with considerably less code
> writing. JBoss Seam is a good example of what I have in mind.
> AJAX+REST friendliness
> ======================
> IMHO the preferred webapp architecture will move from MVC model 2
> towards the kind of architecture described in figure 2 in
> and in
> One way to support such a architectural style with our forms framework
> would be to refactor it so that it allows for a more RESTish
> communication style. Think about the form instance as a resource that
> can have JSON (or XML) representation that you can GET, PUT, POST or
> DELETE. One could also have support for letting the client ask for
> tthe data types of the form for supporting client side validation.

I heartfully agree with these goals and it's true that CForms, more than
old-fashioned, looks heavyweight compared to more recent solutions that
considered partial page update and/or RPC-style interaction right from
the beginning.

Now the question that comes to mind when considering these goals is: "Is
this still Cocoon?"

So what is Cocoon:
- an XML processing engine?
- a REST platform (sitemap matchers)?
- a webapp framework (flowscript, CForms)?
- a block container for Spring components?
- an OSGi bridge/integration platform for blocks?

The still unique distinguishing features of Cocoon are the two first
ones. When we progress in the stack, more competition and more modern
solutions appear. Also, XML processing is powerful for data aggregation,
filtering and transformation, but quickly shows its limits for business
logic (nah, XSP+SQLTransformer is not a nice solution).

For RPC-style webapps, you definitely don't need Cocoon, because there's
no need for XML anywhere. Just use Dojo/Prototype and DWR [1] connected
to plain Java code. For component-based webapps with partial page
updates, Wicket [2] is really productive. All this actually reminds me
of some old prophecy [3].

Rather than coming with its own solution for each and every aspect of
server-side app development, the future of Cocoon is IMHO paradoxically
in its past: XML processing engine and REST platform. By providing a
very simple way to integrate these features in any context, it will
allow people that use other more modern/mainstream approaches to use Cocoon.

A very concrete example: within a Wicket application, we needed to have
areas of the screen be the result of the transformation of some XML
document. We ended up doing coding pipelines in plain Java. If Cocoon
had provided a simple way to use its pipeline machinery, we would have
used it.

All this to say that by trying to address too many concerns, Cocoon
dilutes the message of where its strengths are, and leads potential
newcomers to simply look somewhere else.

A way to address this would be to have several subprojects in the Cocoon
top-level project, ensuring a greater technical separation, giving a
clear view of the various features the top-level project provides and
thus allowing people to pick-up what they need, and ultimately use more
and more of what this project provides. And also providing bridges to
the other mainstream solutions rather than trying to embrace them, thus
giving mindshare to Cocoon in other communities.



Sylvain Wallez -

View raw message