cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: [CForms] Streaming out widget attributes?
Date Thu, 03 Aug 2006 09:31:58 GMT

Sylvain Wallez wrote:

> Antonio Gallardo wrote:
>>> - since only CForms has Ajax integration, people are over-using it
>>> for presentation purposes (e.g. paginated repeater)
>> I agree with you, mixing binding with form definition is not good. We
>> want to keep it separated. However, I think it is a first
>> implementation wich show us a way to implement a paginated repeater
>> after all it is not released yet. It is a work in progress. Is not
>> fair to blame to a first draft implementation.
yes, but it's committed and asked for review :)

> I don't blame any implementation, but think the concept is
> criticizable. Using a form object model and flowscript to paginate a
> result table seems overkill to me.

While I think cocon should have ajax facilities not only in CForms (and
implement some Wicket/Ruby/Gwt paradigms), producing a result table with
cocoon forms seems reasonable to me because, in my experience :
- The result is always following a "query", which quite often is created
using a form before the result page, and the best way to do this is flow
and forms.
- Every other serious framework (including Swing or wicket) actually
uses MVC also for displaying a table of results.
- Even with no query parameters, the result list is often obtained with
some complex logic (hibernate query, calling services, getting spring
beans and so on).
- Since the data you are displaying are usually been inserted by the
user in some other page, you already have the widgets for them, so why
rewrite all the stuff in jx + xsl and not reuse those widgets in output
- The pagination we are implementing is not only for output but also for
input, so that giving the user 50 rows in a repeater does not result in
a 500kb page 3 screens long.

>>> Cocoon allows lots of non-Java people to build complicated stuff,
>>> and this is a major achievement. But I find it easier to write Java
>>> if you're fluent with it rather than finding workarounds in an
>>> XML-centric framework.
>> I feel myself fluent in Java and I still prefer find faster to write
>> a cform application using with cocoon. ;-)
> That's why there's no single silver bullet and one-size-fits-all
> framework!

Being fluent in java allows me to use Javaflow, which is much much
better than javascript, and java components, and still have non java
fluent people take care of presentation and "page" developement. This
can obviously be done in wicket as well, but being the java fluent guy
in wicket means taking care of much more stuff (gui, mandatory fields,
validation) than being the javaflow guy in a cocoon application where
you can focus only on control, eventually binding and backend logic.


View raw message