Introduction
A renderer is an important concept within JSF. It is responsible for creating the HTML output of a page from the Component tree but also processing the response from the browser is their responsibility.
It takes the values from the attributes of a component to do their job. So developers mostly don’t interact directly with them, unless you are writing custom components and write a renderer yourself.
But sometimes it could be handy if we could create some kind of interceptor for the renderers methods so that we could have
- Generic logic for component-based security
- Retrieve validation info (like required, max size) from Beans so that information isn’t defined multiple times.
That is what Jerry and Valerie provide for you.
Origin
The first RendererInterceptor is committed some 10 years ago within the MyFaces-Extensions-CDI project (ExtVal). A set of useful extensions for Java EE programs covering CDI, Bean Validation, and JSF.
With the RendererInterceptor you have a before and after method for every major method in a Renderer which is decode, encodeBegin, encodeChildren, encodeEnd and getConvertedValue.
About 3 years ago, I extracted the RendererInterceptor concept from ExtVal to become Jerry and rewrote it to have a deep integration with CDI and target it exclusively to JSF 2.x. The Validation extensions parts for Bean Validation were bundled into Valerie.
That way, the most powerful code from ExtVal could be used standalone and Jerry could become the heart of the Declarative Permissions based framework Octopus for the JSF component security.
Now, a new rewrite is performed to bring it within the Atbash project family and restrict its usage to Java EE 7 (and later) using the CDI 1.1 features. This is the new release version 0.9.0.
The ComponentInitializer is greatly enhanced which I will explain in this blog.
ComponentInitializer
The ComponentInitializer is a specialized form of a RendererInterceptor and can change the JSF component just before it is encoded (HTML is generated) by the Renderer.
This can be handy if you want to perform some cross-cutting concern, so for all JSF components or all components of a certain type (input type) without the need to actually know all these JSF components or even adjust the renderers.
Classic examples are
- Change the rendered attribute based on the presence of an inner tag to have declarative Component security (This is what Octopus does)
- Change the look of components, like setting the background color of all required input fields.
- Retrieve information from bean properties (like @NotNull) and set the required property. That way information is only required on the model classes and doesn’t need to be duplicated on the JSF components (This is what Valerie does)
@ApplicationScoped
public class RequiredInitializer implements ComponentInitializer {
@Override
public void configureComponent(FacesContext facesContext, UIComponent uiComponent, Map<String, Object> metaData) {
InputText inputText = (InputText) uiComponent;
String style = inputText.getStyle();
if (style == null) {
style = "";
}
if (inputText.isRequired()) {
style = style + " background-color: #B04A4A;");
} else {
style = style.replace("background-color: #B04A4A;","");
}
inputText.setStyle(style);
}
@Override
public boolean isSupportedComponent(UIComponent uiComponent) {
return uiComponent instanceof InputText;
}
}
The above example sets the background color of all input fields if they are required. This is just an example and probably you should implement such a functionality using styleClasses so that color can be defined outside the code in CSS.
All CDI beans implementing the ComponentInitializer interface are picked up automatically and applied to the correct JSF components based on the return value of the isSupportedComponent() method.
Due to the enhanced functionality within this version, a ComponentInitializer can be executed multiple times and thus we need to ‘undo’ our changed style in case the component is not required.
Just as in the previous release, by default, the ComponentInitializer is executed only once. When due to AJAX request, for example, the component is rendered again, the ComponentInitializer isn’t executed anymore. This is done to minimize the overhead of the feature.
However, when the component is in some kind of repeatable parent component, the Initializer is executed multiple times. The repeatable constructs detected are <ui:repeat> and UIData constructs like <h:datatable>.
This is required because the information can be different for each row like the case where the input field required property depends on the row (required=”#{_row.field.required}”)
This logic is added in this release and important to know when you upgrade from an older version.
RepeatableComponentInitializer
The new RepeatableComponentInitializer construction in this release is always executed, regardless of the ‘location’ of the component.
A use-case for this situation is the fact that a PrimeFaces table footer is always present, although no pagination is shown (resulting in a thin colored line). With a RepeatableComponentInitializer you can remove this footer (or upgrade to the upcoming 6.2 version where this is fixed by PrimeFaces code.
Setting up
You just need to add the Jerry (and/or Valerie) maven dependency to your JSF application.
<dependency>
<groupId>be.atbash.ee.jsf</groupId>
<artifactId>jerry</artifactId>
<version>${atbash.jerry.version}</version>
</dependency>
And you are ready to go.
Some more information can be found in the user manuals for Jerry and Valerie.
When you have an application using an older version of Jerry and/or Valerie (0.4.1 and older) you can use the code within the Atbash migrator project to help you convert the import statements, dependencies and JSF namespaces to the new Atbash values.
Conclusion
With the RendererInterceptor you can perform all kind of useful code in a generic way, without knowing or changing the Renderers. The new release has a greatly improved ComponentInitializer execution (detecting repeated structures like <ui:repeat> and <h:dataTable>), the new RepeatableComponentInitializer concept and is part of the ever-growing Atbash projects.
Have fun.