title: The best JSF coding pattern for editing JPA entities using @RequestScoped only
body: <p>I am in a project where I will write a lot of pages like this, so I want to use the most efficient (to write) coding pattern.</p>
  
  <p>Background:  In the past I have used CODI's @ViewAccessScoped to preserve state between requests, and more recently I have started using flash scoped objects to save state.   I can't use JSF @ViewScoped because I use CDI and they don't play well together.   So I want to see if I can do this with only @RequestScoped backing beans.</p>
  
  <p>The page is designed like this (the p namespace is Primefaces):</p>
  
  <pre><code>            &lt;f:metadata&gt;
                  &lt;f:viewParam name="ID" value="#{backing.id}" /&gt;
              &lt;/f:metadata&gt;
  
                  ....
  
              &lt;h1&gt;Edit Object Page&lt;/h1&gt;
  
              &lt;h:form id="formObj" rendered="#{backing.accessOK}"&gt;
  
                  &lt;p:panelGrid columns="2"&gt;
  
                      &lt;h:outputLabel value="Field #1:"/&gt;
                      &lt;p:inputText value="#{backing.record.field1}" /&gt;
  
                            (more input fields)
  
                      &lt;h:outputLabel value="Action:" /&gt;
                      &lt;h:panelGroup&gt;
                          &lt;p:commandButton value="Save"
                                           action="#{backing.save}"
                                           /&gt;
                          &lt;p:commandButton value="Cancel" action="backing.cancel" /&gt;
                      &lt;/h:panelGroup&gt;
  
                  &lt;/p:panelGrid&gt;
                  &lt;p:messages showDetail="true" showSummary="true" /&gt;
  
              &lt;/h:form&gt;
  </code></pre>
  
  <p>If the page is requested, the method <strong>accessOK()</strong> has the ability to keep the <strong>h:form</strong> from being rendered.  Instead, the <strong>p:messages</strong> is shown with whatever <strong>FacesMessage</strong>(s) the <strong>accessOK()</strong> method cares to set.</p>
  
  <p>The pattern for the bean <strong>backing</strong> looks like this:</p>
  
  <pre><code>@Named
  @RequestScoped
  public class Backing {
  
      private long id;
      private SomeJPAEntity record;
      private Boolean accessOK;
  
      public long getId() { return id; }
  
      public void setId(long value) { id = value; }
  
      public boolean accessOK() {
          if (accessOK != null) return accessOK;
  
          if (getRecord() == null) {
               // add a FacesMessage that explains the record
               // does not exist
               return accessOK = false;  // note single =
          }
  
          // do any other access checks, such as write permissions
  
          return accessOK = true;
      }
  
      public SomeJPAEntity getRecord() {
          if (record != null) return record;
  
          if (getId() &gt; 0) record = // get the record from DB
          else record = new SomeJPAEntity();
  
          return record;
      }
  
      public String execute() {
  
           if (!accessOK()) return null;   // bad edit
  
           // do other integrity checks here.  If fail, set FacesMessages
           // and return null;
  
           if (getId() &gt; 0) // merge the record back into the data base
           else  // persist the record
  
      }
  
  }
  </code></pre>
  
  <p>Here is what goes wrong with this model.  When the Save button is clicked, a new instance of <strong>Backing</strong> is built, and then there are a lot of calls to the <strong>getRecord()</strong> getter <em>before</em> the <strong>setID()</strong> setter is called.  So the logic in <strong>getRecord()</strong> breaks because it cannot rely on the <strong>id</strong> property being valid when it is called.</p>
  
  <p>When this was a <strong>@ViewAccessScoped</strong> (or <strong>ViewScoped</strong>) backing bean, then both the <strong>id</strong> and <strong>record</strong> properties are already set when the form is processed with the <strong>commandButton</strong>.   Alternatively you can save those properties in flash storage but that has its own problems I want to avoid.</p>
  
  <p>So is there a way to make this programming model work within the specification?</p>
  
  <p><em><strong>UPDATE:</em></strong></p>
  
  <p>I have a work-around that empirically allows this to work without resorting to either flash or view-scoped variants.  As mentioned above, when the form is processed there are a number of calls to <strong>getRecord()</strong> <em>before</em> the first call to <strong>setId()</strong>.   Then at last the <strong>save()</strong> method is called.</p>
  
  <p>What I do is modify <strong>setId()</strong> as follows:</p>
  
  <pre><code>public void setId(long value) {
    id = value;
    record = null;
  }
  </code></pre>
  
  <p>This forces the <strong>getRecord()</strong> to re-compute (i.e. fetch/build) the property <strong>record</strong>, then subsequent calls work.  Specifically the <strong>save()</strong> method is entered with the object properly initialized including the contents of the <strong>record</strong> entity.   I have no idea what all the prior calls to <strong>getRecord()</strong> were for.</p>
  
  <p>At this point what I also don't know I can rely on is whether all the values written into the <strong>record</strong> entity will be transferred from the <strong>UIinput</strong> components <em>after</em> <strong>getId()</strong> is set.  If so, then I can use this pattern.  Is this controlled by the specification or is it working just by luck?  </p>
  
  <p>Any comments or suggestions?</p>