From adffaces-user-return-1645-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Wed Dec 20 16:30:43 2006
Return-Path: <adffaces-user-return-1645-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org
Received: (qmail 75211 invoked from network); 20 Dec 2006 16:30:43 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
  by minotaur.apache.org with SMTP; 20 Dec 2006 16:30:43 -0000
Received: (qmail 37469 invoked by uid 500); 20 Dec 2006 16:30:50 -0000
Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org
Received: (qmail 37456 invoked by uid 500); 20 Dec 2006 16:30:50 -0000
Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:adffaces-user-help@incubator.apache.org>
List-Unsubscribe: <mailto:adffaces-user-unsubscribe@incubator.apache.org>
List-Post: <mailto:adffaces-user@incubator.apache.org>
List-Id: <adffaces-user.incubator.apache.org>
Reply-To: adffaces-user@incubator.apache.org
Delivered-To: mailing list adffaces-user@incubator.apache.org
Received: (qmail 37446 invoked by uid 99); 20 Dec 2006 16:30:49 -0000
Received: from herse.apache.org (HELO herse.apache.org) (140.211.11.133)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 08:30:49 -0800
X-ASF-Spam-Status: No, hits=-0.0 required=10.0
	tests=SPF_HELO_PASS
X-Spam-Check-By: apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Received: from [213.205.33.42] (HELO mail-relay-2.tiscali.it) (213.205.33.42)
    by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 08:30:38 -0800
Received: from [192.168.0.3] (84.223.104.245) by mail-relay-2.tiscali.it (7.2.078)
        id 458683D900050E40 for adffaces-user@incubator.apache.org; Wed, 20 Dec 2006 17:30:15 +0100
Message-ID: <45896542.9000103@tecnotp.it>
Date: Wed, 20 Dec 2006 17:30:58 +0100
From: Renzo Tomaselli <renzo.tomaselli@tecnotp.it>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To:  adffaces-user@incubator.apache.org
Subject: [Trinidad] rendering disabled tr:commandButton
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

Hi, after replacing h:commandButton by tr:commandButton, I noticed an 
unpleasant rendering effect for disabled buttons.
For example, this button

<tr:commandButton id="changePwd" text="Change password" 
action="#{loginBean.changePwdAction}" 
disabled="#{loginBean.changePwdDisabled}"/>

while disabled is rendered as:

<button id="login:changePwd"
    name="login:changePwd"
    type="button"
    disabled
    class="af_commandButton p_AFDisabled">
        Change password
</button>

and while enabled as:

<button id="login:changePwd"
    name="login:changePwd"
    type="button"
    onclick="submitForm('login',1,{source:'login:changePwd'});return false;"
    class="af_commandButton">
        Change password
</button>

if starting as disabled, this rendering prevents any javascript 
switching to enabled according to other page conditions - such as radio 
selection - since there would be no action. The only way would be to 
follow the very Trinidad-specific onclick based action handling, e.g. 
adding/removing the onclick attribute.
Standard switching used to work well with core h:commandButton, where 
action is always there, no matter disabled status.
Is this kind of rendering an option vs. standard button/action association ?
-- Renzo