Tapestry 5
  1. Tapestry 5
  2. TAP5-1628

Have Submit documentation explicitly state when the disabled attribute is evaluated

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Fixed
    • Affects Version/s: 5.3
    • Fix Version/s: 5.3
    • Component/s: documentation
    • Labels:

      Description

      The "disabled" attribute for a Submit button is currently loosely documented as :

      " ... Further, a disabled field ignores any value in the request when the form is submitted."

      http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/corelib/components/Submit.html

      I would like it to be more explicit, along the lines of:

      " ... Further, if bound, the disabled attribute is re-evaluated upon form submission and the "selected" event is only fired should it evaluate to 'false'."

      For this stumped us in work today for a good half hour - it was because we weren't @Persist'ing our disabled attribute. Our expression was t:disabled="!myObject" and of course 'myObject' because null / false on form submission. As our submit button was enabled and the form submitted, we saw no reason for the event not to fire.

        Activity

        Hide
        Bob Harner added a comment -

        Fixed in rev 1165938, although with different text:

        If true, then the field will render out with a disabled attribute
        (to turn off client-side behavior). When the form is submitted, disabled
        fields' values are ignored (not even validated), and the component's
        events, if any, are not fired.

        But I'm not sure a better description of the disabled parameter helps people know when to apply the @Persist annotation.

        Show
        Bob Harner added a comment - Fixed in rev 1165938, although with different text: If true, then the field will render out with a disabled attribute (to turn off client-side behavior). When the form is submitted, disabled fields' values are ignored (not even validated), and the component's events, if any, are not fired. But I'm not sure a better description of the disabled parameter helps people know when to apply the @Persist annotation.
        Hide
        Hudson added a comment -

        Integrated in tapestry-trunk-freestyle #506 (See https://builds.apache.org/job/tapestry-trunk-freestyle/506/)
        Fixed TAP5-1628 (Have Submit documentation explicitly state when the disabled attribute is evaluated), javadoc changes only.

        bobharner : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1165938
        Files :

        • /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/base/AbstractField.java
        • /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Submit.java
        Show
        Hudson added a comment - Integrated in tapestry-trunk-freestyle #506 (See https://builds.apache.org/job/tapestry-trunk-freestyle/506/ ) Fixed TAP5-1628 (Have Submit documentation explicitly state when the disabled attribute is evaluated), javadoc changes only. bobharner : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1165938 Files : /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/base/AbstractField.java /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Submit.java
        Hide
        Steve Eynon added a comment -

        It is less to do with the @Persist annotation and more to do with not knowing the disabled parameter is used / re-evaluated during the server-side form submit event.

        Once the <input> element has rendered, it is not obvious the disabled parameter will ever be used / re-evaluated again, for I would expect it's sole purpose is to only render the HTML "disabled" attribute.

        I guess I should (have) really ask(ed) why the disabled parameter is evaluated again on form submission, for this not effectively prevent you from re-enabling the component (via javascript) on the web page?

        Show
        Steve Eynon added a comment - It is less to do with the @Persist annotation and more to do with not knowing the disabled parameter is used / re-evaluated during the server-side form submit event. Once the <input> element has rendered, it is not obvious the disabled parameter will ever be used / re-evaluated again, for I would expect it's sole purpose is to only render the HTML "disabled" attribute. I guess I should (have) really ask(ed) why the disabled parameter is evaluated again on form submission, for this not effectively prevent you from re-enabling the component (via javascript) on the web page?
        Hide
        Steve Eynon added a comment -

        Um, I mean, "...for does this not effectively..."

        Show
        Steve Eynon added a comment - Um, I mean, "...for does this not effectively..."
        Hide
        Bob Harner added a comment -

        Okay, I get it. How about the following:

        If true, then the field will render out with a disabled attribute
        (to turn off client-side behavior). When the form is submitted
        the bound value is checked again and, if true, the field's
        value is ignored (not even validated) and the component's
        events are not fired.

        Show
        Bob Harner added a comment - Okay, I get it. How about the following: If true, then the field will render out with a disabled attribute (to turn off client-side behavior). When the form is submitted the bound value is checked again and, if true, the field's value is ignored (not even validated) and the component's events are not fired.
        Hide
        Steve Eynon added a comment -

        Yep, sounds good! Thanks!

        Though I prefer the term similar to "re-evaluated" over "checked" so you know the whole expression is, err, evaluated , and it's not just some cached value being checked. But anything is better nothing, so, um, cheers!

        Show
        Steve Eynon added a comment - Yep, sounds good! Thanks! Though I prefer the term similar to "re-evaluated" over "checked" so you know the whole expression is, err, evaluated , and it's not just some cached value being checked. But anything is better nothing, so, um, cheers!
        Hide
        Bob Harner added a comment -

        Okay, changed to:

        If true, then the field will render out with a disabled attribute
        (to turn off client-side behavior). When the form is submitted, the
        bound value is evaluated again and, if true, the field's value is
        ignored (not even validated) and the component's events are not fired.

        Show
        Bob Harner added a comment - Okay, changed to: If true, then the field will render out with a disabled attribute (to turn off client-side behavior). When the form is submitted, the bound value is evaluated again and, if true, the field's value is ignored (not even validated) and the component's events are not fired.
        Hide
        Hudson added a comment -

        Integrated in tapestry-trunk-freestyle #511 (See https://builds.apache.org/job/tapestry-trunk-freestyle/511/)
        TAP5-1628 minor rewording (javadoc only)

        bobharner : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167084
        Files :

        • /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/base/AbstractField.java
        • /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Submit.java
        Show
        Hudson added a comment - Integrated in tapestry-trunk-freestyle #511 (See https://builds.apache.org/job/tapestry-trunk-freestyle/511/ ) TAP5-1628 minor rewording (javadoc only) bobharner : http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1167084 Files : /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/base/AbstractField.java /tapestry/tapestry5/trunk/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Submit.java

          People

          • Assignee:
            Bob Harner
            Reporter:
            Steve Eynon
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development