This content has been marked as final.
Show 3 replies
-
1. Re: a4j:commandButton disabled attribute with request scoped
shadowcreeper Sep 11, 2008 4:34 PM (in response to shadowcreeper)Since no response, I assume this is a bug.
Posted: https://jira.jboss.org/jira/browse/RF-4458
Thanks.
-Shadow -
2. Re: a4j:commandButton disabled attribute with request scoped
ilya_shaikovsky Sep 12, 2008 8:02 AM (in response to shadowcreeper)Not a bug mark.
Checked at JSF 1.2 RI
next code present at commandLinkRenderer (not a4j one but standard h: one)public void decode(FacesContext context, UIComponent component) { rendererParamsNotNull(context, component); if (!shouldDecode(component)) { return; }
and this is inside htmlBasicRenderer:protected boolean shouldDecode(UIComponent component) { if (Util.componentIsDisabledOrReadonly(component)) { if (logger.isLoggable(Level.FINE)) { logger.log(Level.FINE, "No decoding necessary since the component {0} is disabled or read-only", component.getId()); } return false; } return true; }
And in the end the method from Util classpublic static boolean componentIsDisabledOrReadonly(UIComponent component) { return Boolean.valueOf(String.valueOf(component.getAttributes().get("disabled"))) || Boolean.valueOf(String.valueOf(component.getAttributes().get("readonly"))); }
So you could see this for standard Sun JSF RI component.
As for myFaces - yes sometimes there is differences in implementation. But I do not think that this could prove RF buggy behaviour for this case. -
3. Re: a4j:commandButton disabled attribute with request scoped
shadowcreeper Sep 12, 2008 2:03 PM (in response to shadowcreeper)Thanks Ilya,
I didn't realize that this was intended.
I still don't understand *why* this would be desired, but I'll have to ask that on the Sun forums.
PS -- Thanks for pointing me toward those classes, I didn't realize the attributes Map would expand the EL for you on demand (gotta love the opensource projects).