From adffaces-user-return-1646-apmail-incubator-adffaces-user-archive=incubator.apache.org@incubator.apache.org Wed Dec 20 16:36:43 2006 Return-Path: Delivered-To: apmail-incubator-adffaces-user-archive@locus.apache.org Received: (qmail 78249 invoked from network); 20 Dec 2006 16:36:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 20 Dec 2006 16:36:42 -0000 Received: (qmail 54050 invoked by uid 500); 20 Dec 2006 16:36:49 -0000 Delivered-To: apmail-incubator-adffaces-user-archive@incubator.apache.org Received: (qmail 54035 invoked by uid 500); 20 Dec 2006 16:36:48 -0000 Mailing-List: contact adffaces-user-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: adffaces-user@incubator.apache.org Delivered-To: mailing list adffaces-user@incubator.apache.org Received: (qmail 54026 invoked by uid 99); 20 Dec 2006 16:36:48 -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:36:48 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (herse.apache.org: domain of mwessendorf@gmail.com designates 64.233.182.190 as permitted sender) Received: from [64.233.182.190] (HELO nf-out-0910.google.com) (64.233.182.190) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 20 Dec 2006 08:36:39 -0800 Received: by nf-out-0910.google.com with SMTP id a4so2756470nfc for ; Wed, 20 Dec 2006 08:36:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=nf/hWcFjy7NkwAvJXSW9g1R5YnK+HdviJHkV/oeF8Y+ZCK+dXDduPfgrTSIb8MaORfJVV8H4s5IzCUFE1CoNk1msEGzvAHchJkqB0ZdpqD/EiGfr+qtTjfqdISK08njw/Xv+au2F8eJOuVl/yb70t8DG4ABobZdIJvXa2Iz/RRc= Received: by 10.49.107.8 with SMTP id j8mr205016nfm.1166632577958; Wed, 20 Dec 2006 08:36:17 -0800 (PST) Received: by 10.48.243.14 with HTTP; Wed, 20 Dec 2006 08:36:17 -0800 (PST) Message-ID: <71235db40612200836p1fd5d5b8icf0be1aa1cd2a338@mail.gmail.com> Date: Wed, 20 Dec 2006 17:36:17 +0100 From: "Matthias Wessendorf" Sender: mwessendorf@gmail.com To: adffaces-user@incubator.apache.org Subject: Re: [Trinidad] rendering disabled tr:commandButton In-Reply-To: <45896542.9000103@tecnotp.it> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45896542.9000103@tecnotp.it> X-Google-Sender-Auth: d53ad25dfc6df6d3 X-Virus-Checked: Checked by ClamAV on apache.org you can use ppr for that. like ... ... On 12/20/06, Renzo Tomaselli wrote: > Hi, after replacing h:commandButton by tr:commandButton, I noticed an > unpleasant rendering effect for disabled buttons. > For example, this button > > action="#{loginBean.changePwdAction}" > disabled="#{loginBean.changePwdDisabled}"/> > > while disabled is rendered as: > > > > and while enabled as: > > > > 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 > > -- Matthias Wessendorf http://tinyurl.com/fmywh further stuff: blog: http://jroller.com/page/mwessendorf mail: mwessendorf-at-gmail-dot-com