you can use ppr for that.
like
...
<tr:selectOneRadio value="#{bean.ref}" label="Select One:"
autoSubmit="true"
id="select1">
<tr:selectItem label="on" value="true"/>
<tr:selectItem label="of" value="false"/>
</tr:selectOneRadio>
...
<tr:commandButton partialTriggers="select1" disabled="{bean.ref}"... />
On 12/20/06, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
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
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
