cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leszek Gawron <lgaw...@mobilebox.pl>
Subject [OT] Re: [CForms] Streaming out widget attributes?
Date Thu, 03 Aug 2006 15:08:57 GMT
Simone Gianni wrote:
> 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.

+1. Cocoon has become a web application framework a long time ago even 
though it's first steps were in other direction. Every web application 
at some point needs to use some variation of ValueList for displaying 
tabular data (70% of my GUIs are value lists, the rest are plain CForms 
for editing beans). I would be thrilled if we had some kind of ValueList 
component based on CForms that:

- displays a value list consisting of several columns
- allows for sortable columns (direction indicator and such)
- displays some filtering form widgets
- manages navigation
    - first, previous, next, last buttons
    - goto page button
    - set number of entries per page
- is capable of rows selection
    - single
    - multiple
- is capable of running value list events
    - e.g. ContactValueList would have: deleteSelected, addContact, 
editContact and such.

My current implementation is an utter crap (I am ashamed I am not able 
to come up with something more sophisticated).

Going further: we could provide some kind of pattern for application 
menus and toolbars.

-- 
Leszek Gawron                                      lgawron@mobilebox.pl
IT Manager                                         MobileBox sp. z o.o.
+48 (61) 855 06 67                              http://www.mobilebox.pl
mobile: +48 (501) 720 812                       fax: +48 (61) 853 29 65

Mime
View raw message