a4j:commandButton disabled attribute with request scoped bea

[shadowcreeper]

I'm using JBoss 4.0.5, Facelets and RF 3.2.2.CR4.

When I use an a4j:commandButton and disabled="#{booleanELForRequestScopedBean}"...

If it *was* disabled, behavior is as expected (clicking does nothing).

If it was *not* disabled however, when I click on it, it starts up my "status" node, then creates a new instance of my bean to check the disabled EL before running the actionListener or submitting any form data to the bean, which fails because the bean's data was empty, stops the "status" display and does not run the actionListener or submit any form data.

<a4j:commandButton styleClass="#{bean.updateable ? 'textButton' : 'disabledTextButton'}"
 disabled="#{!bean.updateable}"
 title="Save Changes"
 value="Update"
 status="mainStatusPanel"
 data="#{bean.lastCommandData}"
 actionListener="#{bean.saveChanges}"
 oncomplete="if( data.succeeded ) refreshStuff();"/>

Note: The model is updated via an actionListener right before showing the modalPanel. It should not use initial values after this, but will be updated on submit of the form right before the controller writes the data to the database.

I *can* fix this by setting fake defaults that make the disabled check false. These values will then get overwritten by the form submission before reRendering the button (disabled or otherwise).

Is this a bug? If not, could somebody please point me towards an explanation of why this is desired.

Thanks
-Shadow

[shadowcreeper]

Since no response, I assume this is a bug.

Posted: https://jira.jboss.org/jira/browse/RF-4458

Thanks.
-Shadow

[ilya_shaikovsky]

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 class

 public 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.

[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).