3 Replies Latest reply on Jul 25, 2009 6:58 PM by asookazian

    AJAX and @Out properties in Session POJO beans

    vitorsouzabr

      Hello all,


      I got a session-scoped POJO named manageMailingListsAction that inherits the following properties from a superclass that is a generic CRUD controller:


      @DataModel
      protected List<T> crudEntities;
      
      @DataModelSelection("crudEntities")
      protected T crudSelectedEntity;



      The view is formed by two pages: list.xhtml (shows the existing entities in the database and links to creating and updating entities) and form.xhtml (form used to create and update entities).


      In form.xhtml, I have the following definition of a field for the entity's name:


      <s:decorate id="nameDecoration" template="/resources/templates/formfield.xhtml">
           <ui:define name="label"><h:outputText value="#{messages['form.name']}" /></ui:define>
           <h:inputText id="name" value="#{crudSelectedEntity.name}" size="30" required="true">
                <a4j:support event="onblur" reRender="nameDecoration" bypassUpdates="true" />
           </h:inputText>
      </s:decorate>



      The decorator includes the <s:validateAll> tag as suggested in Seam's reference documentation.


      Finally, here's the question: every component of the page works fine when referring to the #{crudSelectedEntity} component that, thanks to the @Out annotation, has been placed in the Session (as far as I understand). However, when I leave the field, the AJAX request produces an exception:


      "javax.el.PropertyNotFoundException: /form.xhtml @41,115 value="#{crudSelectedEntity.name}": 
      Target Unreachable, identifier 'crudSelectedEntity' resolved to null"



      It's resolved to null only for the AJAX request. If I remove the AJAX, everything works fine.


      Any ideas?


      Thanks,


      Vítor Souza

        • 1. Re: AJAX and @Out properties in Session POJO beans
          asookazian

          @DataModelSelection is used to inject the selected entity as per the row clicked in a dataTable.


          So this does not make sense to me:


          <h:inputText id="name" value="#{crudSelectedEntity.name}" size="30" required="true">



          When JSF renders this facelet, is crudSelectedEntity available in any scope like conversation or session and if so, is it null or not?  The only way it would be available in one of those scopes is if it was outjected in one of your Seam components.


          are you saying that if you simply remove this line:


          <a4j:support event="onblur" reRender="nameDecoration" bypassUpdates="true" />



          everything works fine?

          • 2. Re: AJAX and @Out properties in Session POJO beans
            vitorsouzabr

            Sorry, my mistake, when I deleted the comments from the code I also deleted a very important annotation: @Out


            @DataModelSelection("crudEntities")
            @Out(required = false)
            protected T crudSelectedEntity;



            However, forget the question. In a new round of tests I can't seem to reproduce the problem I was having. It's probably some other mistake that I made. If only you guys got a nickle every time that happens, huh? :) Sorry...


            Everything works in the form now, including AJAX. I'm still getting some weird behavior elsewhere though. When I submit the form with a change in the entity, the entity doesn't change. If I change the access from @Out and #{crudSelectedEntity} to get/set and #{manageMailingListsAction.crudSelectedEntity} it works...


            I'll look into it and make some more tests though. Maybe it's another mistake of mine that I'm overseeing.


            Thanks for the reply,


            Vítor Souza

            • 3. Re: AJAX and @Out properties in Session POJO beans
              asookazian

              Don't overuse outjection.  There was a thread in this forum recently on that.  Excessive bijection makes it difficult to know where the instances are coming from.  But with getter/setter, it's obvious.  I would probably stick with your getter/setter refactoring unless there's any problems...