Return-Path: 
 <commits-return-13883-apmail-tapestry-commits-archive=tapestry.apache.org@tapestry.apache.org>
X-Original-To: apmail-tapestry-commits-archive@minotaur.apache.org
Delivered-To: apmail-tapestry-commits-archive@minotaur.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 56D897986
	for <apmail-tapestry-commits-archive@minotaur.apache.org>;
 Thu,  8 Sep 2011 07:19:47 +0000 (UTC)
Received: (qmail 20687 invoked by uid 500); 8 Sep 2011 07:19:44 -0000
Delivered-To: apmail-tapestry-commits-archive@tapestry.apache.org
Received: (qmail 20493 invoked by uid 500); 8 Sep 2011 07:19:35 -0000
Mailing-List: contact commits-help@tapestry.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@tapestry.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@tapestry.apache.org>
List-Post: <mailto:commits@tapestry.apache.org>
List-Id: <commits.tapestry.apache.org>
Reply-To: dev@tapestry.apache.org
Delivered-To: mailing list commits@tapestry.apache.org
Received: (qmail 20466 invoked by uid 99); 8 Sep 2011 07:19:31 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Sep 2011 07:19:31 +0000
X-ASF-Spam-Status: No, hits=-2000.5 required=5.0
	tests=ALL_TRUSTED,RP_MATCHES_RCVD
X-Spam-Check-By: apache.org
Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Sep 2011 07:19:29 +0000
Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116])
	by hel.zones.apache.org (Postfix) with ESMTP id E435088AF1
	for <commits@tapestry.apache.org>; Thu,  8 Sep 2011 07:19:08 +0000 (UTC)
Date: Thu, 8 Sep 2011 07:19:08 +0000 (UTC)
From: "Steve Eynon (JIRA)" <jira@apache.org>
To: commits@tapestry.apache.org
Message-ID: 
 <1709696849.2035.1315466348931.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1985994429.14484.1315039209905.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (TAP5-1628) Have Submit documentation explicitly
 state when the disabled attribute is evaluated
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394


    [ 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