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 state? - 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. Simone
