I would like to follow the jsf usage for actions. Using the actionlistener attribute is quite easy and provides more information to the user than it does in the current implementation.
Personally I find it a good solution to define an id for each column, place the sortheader component into the column header define actionlistener attribute for the sortheader component with a methodbinding. We would provide a special ActionEvent with properties like the parent column component to make it easy to identify which column should be sorted. The sortheader component won´t be so trivial because it holds it´s state (sort direction and more) between requests and provides a special ActionEvent. The next point is that the current attributes which must be defined are spread over two components which isn´t very intuitive. At least we should think about moving the two attributes from x:datatable to the sortheader component which will work if we fix the problem below. That would reduce the dependancy to x:datatable to nothing. IMO the current implementation of the preservesort=true and preservedatamodel=false doesn´t follow the jsf lifecycle. The preserved values for column name and sort direction are updated in the update model phase which is wrong because the datamodel is already initialized (with a wrong sorting) during the decode phase and will not be reinitialized before the encode phase begins. We have to set the preserved sort values in the restore state phase. This will make the decode phase work right for input fields in the datatable which rows are sorted right when the datamodel is initialized during the decode phase. Mathias > -----Original Message----- > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 07, 2005 3:58 PM > To: MyFaces Development > Subject: Re: Why is immediate=true default for HtmlCommandSortHeader > > > But that would make commandSortHeader trivial, i.e. nothing more than > a commandLink. And the user again has to fumble around with action > methods and listeners and so on. > > The idea is to make the backing bean simple and maintainable for new > columns. All that a table backing bean has to know is the [name] of > the column to be sorted and the [sort direction]. So, all that you > have to do to get a sortable table is: > * give each column a name (=one attribute in commandSortHeader) > * tell MyFaces the two backing bean properties (name and sort > direction) (=two attributes in x:dataTable) > > This is a very simple approach (for the user) and I like it. > So, other than being not intuitive this is more a lack of > documentation I fear - mea culpa ;-) > > WDYT? > > -Manfred > > > 2005/7/7, Broekelmann, Mathias <[EMAIL PROTECTED]>: > > I think we should handle it like the other uicommand > components and set the default immediate flag to false. It is > quite surprisingly for the user who don´t care about this > attribute and expects a different behavior because he thinks > that every command component is working like that way. > > > > If the user want´s to do some fine tuning and don´t need > the standard behavior he can switch the immediate flag to true. > > > > A second thing I came across with was that the usage of the > sortheader component is not very intuitive for the user. He > has to define 3 attributes - 2 for the datatable and one for > the sortheader component. I think it´s better to define a > single action like method attribute which expects a special > signature like: > > > > void <methodBinding>(boolean ascending); > > > > For each column to sort the user normaly defines individual > action methods. > > > > If the user wants a more dynamic way he could use an > <sort>ActionListener which can be registered instead of the > action. The signature of that listener could be: > > > > Void <methodBinding>(SortEvent event); > > > > The event contains the component association which can be > used to determine the column and the sort direction. > > > > That would also make it possible to use the sortheader > component in a normal h:datatable > > > > To make it backward compatible we should create a > x:commandSortHeader2 component. > > > > Mathias > > > > > -----Original Message----- > > > From: Manfred Geiler [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, July 07, 2005 2:52 PM > > > To: MyFaces Development > > > Subject: Re: Why is immediate=true default for > HtmlCommandSortHeader > > > > > > > > > Hmm, quite a long time ago... > > > > > > One thing I have in mind is this: > > > For simple tables (without input components) the validation, model > > > update and so on is not necessary. And even for complex > tables it is > > > the question if it is desireable by default to do those things and > > > display error messages if the user only wanted to resort > the table. > > > i.e. He just wants to change his view. A user clicking on a sort > > > header does not normally have the intention to submit his entries. > > > > > > WDYT? > > > > > > -Manfred > > > > > > > > > 2005/7/7, Broekelmann, Mathias <[EMAIL PROTECTED]>: > > > > Hi, > > > > > > > > Does anyone know why the immediate flag defaults to true for the > > > > sortheader component? IMO we should use the usual default > > > false for the > > > > immediate attribute. > > > > > > > > Mathias > > > > > > > > > >
