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] Modernizing CForms
Date Mon, 19 Mar 2007 21:56:22 GMT
Sylvain Wallez skrev:
> 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
>> http://www-128.ibm.com/developerworks/websphere/library/techarticles/0606_barcia/0606_barcia.html
>>
>> and in http://websphere.sys-con.com/read/196269.htm.
>>
>> 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?"

Considering the excess of ideas, languages and areas that are covered in 
our repository, I'd say that Cocoon seem to be whatever at least one 
comitter want it to be ;)

> 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. 

I'd say that we are in the forefront and have some unique ideas in the 
"block container for Spring components" area as well. But I'm fairly biased.

For OSGi, developing bridge/integration framework is clearly better done 
in other communities. But it would still be nice to apply their results 
at Cocoon.

> 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).

Agree.

> 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.

Yes. Personally I'm much more attracted to AJAX+REST than AJAX+RPC, though.

> 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.

I agree about that XML-pipeline + REST is our core offering and that it 
would deserve more attention and polishing from us.

> 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.

Although it could be even easier and most definitively should require 
less dependencies it is not that hard to use the pipeline standalone: 
http://svn.apache.org/repos/asf/cocoon/whiteboard/java-sitemap/src/main/java/org/apache/cocoon/javasitemap/JavaSitemapServlet.java.

For the dependencies we have done some work on splitting up Cocoon so 
that you can use just the pipeline part (see 
http://svn.apache.org/repos/asf/cocoon/trunk/core/). The main thing left 
to do is to de-Avalonize a number of core components.

> 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.

We clearly need to have a more focused message. But I think that saying 
that we should not provides a webapp framework anymore but just some 
components would be to go far to long. We need to find the right balance.

> 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.

We are going in this direction. Both the cocoon-spring-configurator and 
the cocoon-servlet-service-fw (and maybe some more) are intended to be 
separate Cocoon sub projects. Lots of work left to do though.

> And also providing bridges to
> the other mainstream solutions rather than trying to embrace them, thus
> giving mindshare to Cocoon in other communities.

Exactly.

/Daniel


Mime
View raw message