7 Replies Latest reply on Apr 18, 2007 11:06 AM by Louis Coetzee

    DataModel in two SFSB issues

    Louis Coetzee Apprentice


      I have an interesting issue with DataModels. Any suggestions would be appreciated.

      The setup:
      I have Bean "A" which has a list ("sections") annotated as DataModel. "sections" is available in my current conversation. When invoking a method from my JSF page (which calls a method in my second Bean "B", who also has the "sections" annotated with a DataModel), I run into problems as the "sections" are not available in Bean "B". (I have looked at the conversation context and can see that "sections" has been removed from the context).

      This is quite weird. I then stepped through the Seam code and ran into the following in "Component.java"

      private void outjectDataModel(Object bean, BijectedAttribute dataModelGetter)
       DataBinder wrapper = createWrapper(dataModelGetter.getAnnotation() );//1
       Object list = dataModelGetter.get(bean);//2
       String name = dataModelGetter.getName();
       Annotation dataModelAnn = dataModelGetter.getAnnotation();
       ScopeType scope = wrapper.getVariableScope(dataModelAnn);
       Context context = getOutScope(scope, this).getContext();
       Object existingDataModel = context.get(name);
       boolean dirty = existingDataModel == null || scope==PAGE ||
       wrapper.isDirty(dataModelAnn, existingDataModel, list);//3
       if (dirty)
       if ( list!=null )
       context.set( name, wrapper.wrap(dataModelAnn, list) );

      Line //2 return null for the list value when entering into Bean B while outjecting (seems the list is associated with the bean name, in this case Bean B, in stead of returning the list associated with Bean A, or just by extracting it from the conversation context).

      As a result of the null value Line //3 is always dirty, resulting in the variable being removed from the conversation context !

      Is it possible two have a DataModel used over two SFSB's ? Based on the above Seam code it appears as if a DataModel is hardwired to a specific SFSB.