Question

So let pick a UIComponent like HtmlSelectOneRadio(Please view source here: http://grepcode.com/file/repo1.maven.org/maven2/com.sun.faces/jsf-api/2.1.7/javax/faces/component/html/HtmlSelectOneRadio.java#HtmlSelectOneRadio)

So some of the setters will call method handleAttribute(...), and some does not, for example

public void setDir(java.lang.String dir) {
    getStateHelper().put(PropertyKeys.dir, dir);
    handleAttribute("dir", dir);
}

public void setDisabled(boolean disabled) {
    getStateHelper().put(PropertyKeys.disabled, disabled);
}

and it is very UNCLEAR to me what handleAttribute is doing, can a JSF guru please explain to me what this method try accomplish and why somes attribute call this method while other does not? Thank you so much

Answer 1

It’s related to Mojarra-internal rendering optimizations, wherein only the attributes which are been set by the internal handleAttribute() method are been rendered as so-called “pass-thru” attributes instead of that every single attribute of the component will be checked if it has been set or not, which may end up to be more expensive if there are relatively a lot of attributes. A “pass-thru” attribute is a component attribute which can just be outright rendered without any specific pre/postprocessing.

Peek around in Mojarra’s RenderKitUtils class, starting at the renderPassThruAttributes() method:

316         if (canBeOptimized(component, behaviors)) {
317             //noinspection unchecked
318             List<String> setAttributes = (List<String>)
319               component.getAttributes().get(ATTRIBUTES_THAT_ARE_SET_KEY);
320             if (setAttributes != null) {
321                 renderPassThruAttributesOptimized(context,
322                                                   writer,
323                                                   component,
324                                                   attributes,
325                                                   setAttributes,
326                                                   behaviors);
327             }
328         } else {
329 
330             // this block should only be hit by custom components leveraging
331             // the RI's rendering code, or in cases where we have behaviors
332             // attached to multiple events.  We make no assumptions and loop
333             // through
334             renderPassThruAttributesUnoptimized(context,
335                                                 writer,
336                                                 component,
337                                                 attributes,
338                                                 behaviors);
339         }

The canBeOptimized() returns true if the component is one of the standard JSF components (actually, if the component’s package name starts with javax.faces.component.) and if there is no more than 1 behavior in the behaviors array.

The renderPassThruAttributesOptimized() will only render the attributes which are specified in setAttributes argument.

The renderPassThruAttributesUnoptimized() will loop through every single attribute in the attributes map and check for every single attribute if the associated value is not null/empty and then render it.

---

As to why some attributes are not been set by handleAttribute(), that’s because they require some more specific pre/postprocessing and are already explicitly been rendered by the renderer specific to the component, so they don’t need to be rendered as a “pass-thru” attribute.

---

You don’t need to worry about this when writing custom components. You can always introduce your own optimizations similar to this, but it isn’t recommend to rely on Mojarra-specific internal optimizations as they may not work at all when you’re using MyFaces, for example.