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
