javaeetutorial
  1. javaeetutorial
  2. JAVAEETUTORIAL-159

ajaxguessnumber: possible solutions without js-hack

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 6.0.8
    • Fix Version/s: 7.0.2
    • Component/s: examples
    • Labels:
      None

      Description

      When reading the chapter on the ajaxguessnumber example app and analysing the code, I was surprised at the choice of writing a custom js-function "msg" to get rid of the stale result. Certainly, this allows the demonstration of the h:commandButton's onevent attribute, but:

      • it doesn't seem like a clean solution to me (it doesn't seem very refactoring-friendly because of the 2 getElementById("hard-coded HTML element ID") calls),
      • it doesn't explain the inclusion of the commented-out code <f:ajax execute="userNo" render="result errors1" /> within the code AND the tutorial chapter.

      It looks more like a quick fix by one person (developer) that was later commented on by another person (who wrote the tutorial chapter).

      If one were to want to rewrite the code as it was perhaps originally intended (as is perhaps still visible in the commented-out code aforementioned), I could think of the following two possibilities:

      1. Only render the outputText if there was no validation error.
      2. Change the scope of the ManagedBean from @SessionScoped to @RequestScoped


      The first solution would look something like the following. For it to work with Ajax, the outputText would need to be wrapped in a container such as h:panelGroup and the f:ajax render attribute would need to refer to the panel's ID ("outputGrid"):

      ajaxgreeting.xhtml
      <h:commandButton id="submit" value="Submit" >
          <f:ajax execute="userNo" render="outputGrid" />
      </h:commandButton>
      <h:panelGroup layout="block" id="outputGroup">
          <h:outputText id="result" style="color:blue"
                        value="#{userNumberBean.response}" rendered="#{!facesContext.validationFailed}"/>
          <h:message id="errors1" showSummary="true" showDetail="false"
                     style="color: #d20005;
                     font-family: 'New Century Schoolbook', serif;
                     font-style: oblique;
                     text-decoration: overline" 
                     for="userNo"/>
      </h:panelGroup>
      

      The second solution changes the design altogether. I'm not sure why you would want @SessionScoped for this example in the first place. @RequestScoped seems more appropriate and solves the problem of hiding the "stale output" of the "result" outputText element.

        Activity

        Hide
        swiss-chris added a comment -

        After posting my original proposals, I realized that simply changing the scope from @SessionScoped @RequestScoped wouldn't suffice. While the userNumber could be @RequestScoped, the randomInt needs to be @SessionScoped for the guessing game to give the user a second chance.

        Off hand all I can think of to make this work as I had intended is to create a second dukesNumberBean, also a managed bean that contains the randomInt as well as the minimum and maximum values. I used @ManagedProperty(value="#

        {dukesNumberBean}

        ") to inject it into userNumberBean

        by the way, the value 10 was hardcoded into the userNumberBean constructor. Alternatively, randomInt could be created the following way:

        long range = maximum-minimum+1;
        randomInt = (int)(minimum + randomGR.nextDouble()*range);
        
        Show
        swiss-chris added a comment - After posting my original proposals, I realized that simply changing the scope from @SessionScoped @RequestScoped wouldn't suffice. While the userNumber could be @RequestScoped , the randomInt needs to be @SessionScoped for the guessing game to give the user a second chance. Off hand all I can think of to make this work as I had intended is to create a second dukesNumberBean , also a managed bean that contains the randomInt as well as the minimum and maximum values. I used @ManagedProperty(value="# {dukesNumberBean} ") to inject it into userNumberBean by the way, the value 10 was hardcoded into the userNumberBean constructor. Alternatively, randomInt could be created the following way: long range = maximum-minimum+1; randomInt = ( int )(minimum + randomGR.nextDouble()*range);
        Hide
        Ian Evans added a comment -

        UserNumberBean was changed to request-scoped, and a new session-scoped backing bean, DukesNumberBean, was added. A new panel group was added to display the results or the validation error. These changes eliminate the need for the separate ui.js Javascript file, as stale data should not be a problem.

        These changes probably better reflect how we want users to use the f:ajax tag, but we no longer have an example that uses onevent or shows how to add custom Javascript. Perhaps we need an advanced example?

        Show
        Ian Evans added a comment - UserNumberBean was changed to request-scoped, and a new session-scoped backing bean, DukesNumberBean, was added. A new panel group was added to display the results or the validation error. These changes eliminate the need for the separate ui.js Javascript file, as stale data should not be a problem. These changes probably better reflect how we want users to use the f:ajax tag, but we no longer have an example that uses onevent or shows how to add custom Javascript. Perhaps we need an advanced example?
        Hide
        Ian Evans added a comment -

        Fixed in source and rewrote doc source. The fixes will appear in the next Tutorial update.

        Show
        Ian Evans added a comment - Fixed in source and rewrote doc source. The fixes will appear in the next Tutorial update.

          People

          • Assignee:
            Ian Evans
            Reporter:
            swiss-chris
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 30 minutes
              30m
              Remaining:
              Remaining Estimate - 30 minutes
              30m
              Logged:
              Time Spent - Not Specified
              Not Specified