javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1805

UIComponent attribute defaults are not used when bound to managed bean property by EL, even if the managed bean property is null

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Incomplete
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: facelets
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      1,805
    • Status Whiteboard:
      Hide

      size_medium importance_medium

      Show
      size_medium importance_medium

      Description

      For many UIComponents attributes a default behavior is defined if the attribute
      is not set. But as soon as attributes are bound to managed bean properties, that
      default is never used because the created ValueExpression sets the expected type
      to the UIComponent attributes type and therefore never resolves to null (that's
      how EL type coercion is specified). So if expected type is Integer, you always
      get an Integer - for empyt or null input you get Integer(0).

      Let's look at some component attributes:

      • rendered attribute: null is interpreted as true by default, but with EL null
        becomes false.
      • disable attribute: null is interpreted as false, luckily that is tha same as
        el coerces null to.
      • size/maxlength attributes: if null no size/maxlength attribute is rendered,
        but with EL null becomes size="0"/maxlength="0".
        To handle null on rendered one must reimplement the default handling in the
        expression like rendered="# {empty bean.rendered or bean.rendered}

        ".
        I think that is unnecessary burden to the developer.
        Now look at the difference between rendered and disabled - on rendered case you
        have to check null in el expression, on disabled you don't have to because El
        will coerce to the right default.
        For the size/maxlength attributes the expression would have to return
        Integer.MIN_VALUE if the bean attribute is null (and I guess this "no-value" is
        implementation specific).

      My proposal is to use Object as expectedType for all UIComponent attribute
      mapping EL expressions and do the type conversion later in TagValueExpression,
      which already wraps the javax.el.ValueExpression.

      Attached is a patch for JSF Facelets doing that with little change in
      com.sun.faces.facelets.tag.TagAttributeImpl and
      com.sun.faces.facelets.el.TagValueExpression.
      I made it possible to choose the behavior with a context-param. My tests showed
      no problems using Object as expectedType.

      I also put up a little showcase application online at
      http://www.dueni.ch:8080/jsfweb to demonstrate the difference.
      What is shown there: the nullAttributes example shows the different behavior
      with expectedType=Object/attribute type. For an initial look check
      allowNullExpressionOnComponentAttributes and press "reset initial values". When
      looking at this example also check the generated html - with standard behavior
      and rendered set you will notice size="0" maxlength="0" on the first input field
      of the lower box (because the bean attribute null was converted to 0 by EL).

      I hope we can change this - it would make life of JSF developers easier to not
      having to consider UIComponent attribute dependent default values in EL
      expressions for bean attributes that may be null.

      Kind regards
      Hanspeter

        Activity

        Hide
        Hanspeter Duennenberger added a comment -

        Created an attachment (id=1289)
        intermediate patch for solution verification

        Show
        Hanspeter Duennenberger added a comment - Created an attachment (id=1289) intermediate patch for solution verification
        Hide
        Manfred Riem added a comment -

        Can you let me know which version is affected? Thanks! Can you verify against the latest 2.1 release?

        Show
        Manfred Riem added a comment - Can you let me know which version is affected? Thanks! Can you verify against the latest 2.1 release?
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Closing because of inactivity

        Show
        Manfred Riem added a comment - Closing because of inactivity

          People

          • Assignee:
            Unassigned
            Reporter:
            Hanspeter Duennenberger
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: