3 Replies Latest reply on May 27, 2009 8:19 PM by gonorrhea

    passing param in hasRole call from xhtml

    gonorrhea

      Seam 2.0.2-FP
      RF 3.3.1.GA


      xhtml1:


      <rich:dropDownMenu value="Administration" 
                          rendered="#{s:hasRole('admin')}">




      xhtml2:


      <rich:dropDownMenu value="Administration" 
                     rendered="#{s:hasRole(testSecurity.getRole())}">



      JavaBean:


      @Name("testSecurity")
      @Scope(ScopeType.CONVERSATION)
      public class TestSecurity {
           
           private String role = "admin";
      
           public String getRole() {
                return role;
           }
      
           public void setRole(String role) {
                this.role = role;
           }
      }



      xhtml1 works.  xhtml2 does not call the getRole() method (I have a debug brkpt).  No exceptions in console. 


      Is it possible to do the xhtml2 way?  i.e. I don't want to hard-code the roles in the xhtml for the hasRole() call.  I thought it was possible to pass params in EL method calls via the enhanced JBoss EL...


      thx.

        • 1. Re: passing param in hasRole call from xhtml
          gonorrhea

          I misspoke.  Both examples are passing one param in the EL for hasRole() call.  Was referring to the Seam component method call inside the hasRole()...

          • 2. Re: passing param in hasRole call from xhtml
            gonorrhea

            Why are all the hasRole() examples in the ref doc, SiA and Yuan books hard-coded?


            Isn't it bad practice to be hard-coding role data in xhtml?


            Imagine if you had a very large 100 page JSF/Seam app.  And all the page- and component-level restrictions were hard-coded like that?  What a pain it would be to refactor in case of requirements changes related to security/roles...


            Is this addressed in Seam 2.1 or 3???

            • 3. Re: passing param in hasRole call from xhtml
              gonorrhea

              Ok, nevermind.  It was my mistake after all (as it usually is).


              The TestSecurity class was not packaged in the JAR during the ant build.  But....


              Here is the server.log details regarding this component:


              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.core.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.transaction.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.framework.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.web.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.faces.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.international.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.theme.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.pageflow.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.bpm.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.jms.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.mail.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.security.testSecurity
              2009-05-27 10:24:05,291 DEBUG [org.jboss.seam.Component] seam component not found: org.jboss.seam.captcha.testSecurity



              Note that the logging level is DEBUG.  When a method is missing in a local interface that is impelemented by a SFSB/SLSB component, you see a facelets/JSF error report.  I like that behavior better than what I just experienced with this missing JavaBean component.


              @Seam dev core team:  If there isn't a JIRA already for this, I recommend the logging level and exception handling for this be refactored/improved such that it's easier to notice that something critical (like an entire class!) is missing.  There was no ERROR level logging in the server.log regarding this missing component which is bad IMO.  Behavior similar to the facelet error for missing local interface method would be acceptable/helpful.