[
https://issues.apache.org/jira/browse/TAP5-1628?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13100122#comment-13100122
]
Steve Eynon commented on TAP5-1628:
-----------------------------------
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?
> Have Submit documentation explicitly state when the disabled attribute is
> evaluated
> -----------------------------------------------------------------------------------
>
> Key: TAP5-1628
> URL: https://issues.apache.org/jira/browse/TAP5-1628
> Project: Tapestry 5
> Issue Type: Improvement
> Components: documentation
> Affects Versions: 5.3
> Reporter: Steve Eynon
> Assignee: Bob Harner
> Priority: Trivial
> Labels: submit
> Fix For: 5.3
>
>
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
