Restriction with using DataModelSelection and sorted resultset?

[gonorrhea]

The entity that is being injected does not correspond to what I expect in my dataTable (i.e. the wrong entity/row is injected).  The outjected ListDataModel based on the resultset from Criteria API was sorted as follows:

criteria.addOrder( Order.asc("this.icomsItemNumber") );
                
recoveredEquipmentManagementList = criteria.list();

So if we sort the resultset for our outjected ListDataModel (via @DataModel), should we not use @DataModelSelection and use JBOSS EL instead (i.e. on commandLink in dataTable, pass the row number via foo.getRowIndex())?

I didn't see this in the Seam ref doc...  Plz add to ref doc and/or make this a sticky...

[gonorrhea]

The following seems to be using random entities as well:

<a4j:commandLink value="Edit" 
            ajaxSingle="true"
            action="#{recoveredEquipmentManagement.edit(listVal)}"
            oncomplete="rerenderRecoveredEquipmentManagementModal();"/>

anybody have any workaround for this (other than removing the sorting)?

[kapitanpetko]

I've found @DataModelSelection to be unreliable (at least in 2.0, haven't tried it lately), so you are probably
better off using JBOSS EL. But maybe that was IE's fault, not Seam's. I ditched @DataModelSelection early on
and haven't looked back.

But your problem is, probably, that your @DataModel is not properly refreshed after you sort
(or @DataModelSelection is, for some reason, using the old model).

Try something like this:

Contexts.getConversationContext().remove("recoveredEquipmentManagmentList");

recoveredEquipmentManagementList = criteria.list();

[gonorrhea]

Thanks for the response!

Here is a related thread: http://seamframework.org/Community/DataModelSelectionAndSortByNotFunctional

however, in that thread, the developer was sorting by header clicks, not by 'order by' clause in the generated native SQL.

Right now I seem to have it working fine by passing the entity in the method call to edit().

Somewhere (book, wiki, forum??) I remember reading that sorting of <rich:dataTable> and @DataModelSelection injection don't work properly, but can't recall exactly the root cause and/or workaround or fix for that.  And I do remember experiencing the same problem in the cited thread (clickable header sort messes up the injected entity).

But your problem is, probably, that your @DataModel is not properly refreshed after you sort (or @DataModelSelection is, for some reason, using the old model).

This is most likely not the case.  The @DataModel outjects to the scope of the Seam component (unless otherwise specified as an attribute value), in this case conversation context, and this happens after each successful business method execution.  You would hope that @DataModel and @DataModelSelection are synchronized.  It definitely seems buggy to me...

[kapitanpetko]

Arbi Sookazian wrote on Jun 12, 2009 06:00:


This is most likely not the case.  The @DataModel outjects to the scope of the Seam component (unless otherwise specified as an attribute value), in this case conversation context, and this happens after each successful business method execution.  You would hope that @DataModel and @DataModelSelection are synchronized.  It definitely seems buggy to me...

Well, I might be wrong about your problem, but @DataModel is indeed special.
Cf. Component.outjectDataModel:

boolean dirty = existingDataModel == null ||
            wrapper.isDirty(dataModelAnn, existingDataModel, list);
boolean reoutject = existingDataModel!=null && scope==PAGE;
      
if (dirty)
{
  if ( list!=null )
  {
     context.set( name, wrapper.wrap(dataModelAnn, list) );
  }
  else
  {
    context.remove(name);
 }
}
else if (reoutject)
{
  context.set(name, existingDataModel);
}

wrapper.isDirty (in DataModelBinder) calls equals on the list you are trying to outject and the current one to
determine if it has changed. That is meant to be an optimization, but is quite counter-intuitive,
I think. Premature optimization and all that...

Anyway, if you sort the list, the order changes, so isDirty should return true and the new
Datamodel should be properly outjected. Which proves that I was wrong :)