Writing JSF components is hard and complicated. No one in their right mind writes them. Except when you are a framework developer.
My team is struggling for some time now with Primefaces and its (natural) limitations where one cannot simply change the HTML output to the designers need. So, I spent some days this fall, to try to replace PrimeFaces components with an angular solution, so that PrimeFaces can be completely removed from the application and all components like dialogs or growls are replaced with angular directives.
I didn’t want to use AngularFaces as its trying to put too much magic into the application (for my personal taste). Its very interesting on paper, but when you use it, it seems that every single developer needs to understand exactly both lifecycles of JSF and angularJS and how both frameworks are working. This seems to be a challenge for every decent sized team.
Luckily, the XML parser of JSF leaves HTML tags it does not know of (aka: angularJS directives) alone and just outputs them in the rendered HTML. In a way, that works like the passthrough attributes in JSF 2.2.
As I wanted to use angularJS only as a “widget factory” in a JSF application, I had to solve only a short list of problems:
- adding the ng-app attribute to the h:body tag is not possible when not using JSF 2.2, Solution: manual bootstrapping like described in angularjs documentation or wrapping your JSF template with a div and the ng-app attribute.
- inform angularJS about DOM changes after a JSF AJAX request
- implement a solution so that directives can make JSF AJAX requests, which is not possible out of the box as they can’t have a JSF ID in JSF versions < 2.2
Besides the first, the last two problems were the challenge.
Inform angularJS about DOM changes after a JSF AJAX request
When you load angularJS on page load in a JSF page, its working as expected: its doing its thing and enhances the DOM according to the registered directives. If you don’t use any AJAX requests at all, you are basically done.
The challenge with AJAX requests is, that angularJS needs to be informed about those changes, as they happen outside of an angularJS digest but can contain new DOM nodes with angularJS directives or are destroying/changing existing directives. AngularFaces solved it in a brute-force-like-way: the angularJS app will be completely destroyed and recreated after every JSF AJAX request. But as I only wanted to use directives, that seemed a little harsh for me.
So, after a little experimenting I’m presenting you:
JSF-Updates-Angular (or short: JUA).
Its a (very small) library to update angularJS after every JSF AJAX request:
- adds 2 event listeners to the JSF JS library for the ajaxComplete and ajaxSuccess events
- when ajaxComplete event happens, the DOM nodes that are updated by JSF are still unchanged. JUA will iterate through them, searching for nodes with a scope or isolate scope and call the $destroy method on those scopes. Destroying of scopes is done by angularJS itself.
- when ajaxSuccess event happens, the DOM nodes that are updated by JSF are successfully updated and this library will compile them via angularJS $compile service.
The result is that even DOM nodes which are updated via JSF AJAX requests are enhanced by angularJS directives.
The current state of JUA is not production ready. It was only tested on a few developer machines in a Mojarra JSF 2.1.7 environment (JBoss 7.1.1.). But as I don’t see any JSF dependencies, it should work with any JSF version, provided the JSF AJAX event listener callback interface was not changed.
Trigger JSF AJAX requests inside of directives
When not using JSF 2.2 angularJS directives (aka HTML tags) can’t have JSF IDs and therefore can’t be the source of an JSF AJAX request. But even with JSF 2.2 or when you use a JSF component as a source, you have to build the requests yourself, which is … not so easy.
I made a short-cut here and am using the great OmniFaces library by balusC. With OmniFaces you have a o:commandScript JSF component which registers a global Javascript function to trigger a JSF request. The request can even send a payload with it (PrimeFaces has a similar component). When a angularJS directive needs to send AJAX requests to a managed bean, I’m just using a commandScript call, instead of inventing the wheel again. Works quite nice.
<tabview on-tab-change="makeTabActive">
<h:panelGroup id="tabs">
<tab id="detailTab" title="#{msgs.auftrag}" active="#{bean.detailTabActive">
<h:form id="form">
<o:commandScript name="makeTabActive"
render=":tabs"
execute="@this"
action="#{bean.onTabChangeMethod()}" />
<h:outputText value="Detail Tab Content" />
</h:form>
</tab>
...
</h:panelGroup>
</tabview>
(tabView and tab are angularJS element directives)
Tips
Use OmniFaces. Really, this library is great!
Re-implement your application in angularJS instead of JSF.
Execute javascript after AJAX request is complete
As pure JSF doesn’t have an easy way (is ANYTHING easy in JSF?) to execute Javascript after a JSF AJAX request, you can use OmniFaces Ajax.oncomplete() for this. Or (if you want) use the onComplete/onCompleteEvent function of JUA which guarentees that your callback listener is called AFTER angularJS was updated:
<h:commandLink value="Do Ajax stuff" action="#{bean.method()">
<f:ajax update="@form" execute="@this"
onevent="jua.onCompleteEvent(myDialog.show)" />
</h:commandLink>
Register global function in your directives to call them outside of angularJS digest
My dialog directive – which will be replacing the primefaces dialog component – registers a global javascript function for every dialog name, so that it just can be used like the primefaces dialog. Call dialog.show() anywhere (even in click handlers of JSF components) to show the dialog and dialog.hide() to close it. For developers who don’t know anything about the implementation details, the new dialog behaves just like the PrimeFaces dialog.
$window[scope.dialog] = {
show: function () {
$window.jua.ensureExecutionAfterAjaxRequest(function () {
$scope.apply(function () {
addOverlay();
scope.open = true;
});
});
},
hide: function () {
hide();
}
};
(this code is run inside an angularJS directive)
Make use of OmniFaces library components
Use o:messages of OmniFaces to output JSF messages to mimic the PrimeFaces growl component. With o:messages you can control the HTML output of messages and can give an angularJS directive all needed parameters to mimic a growl message.
<messages sticky="true"
life="20000"
show-detail="trur"
show-summary="true">
<h:panelGroup id="messages">
<o:messages var="message" showSummary="true" showDetail="true">
<message summary="#{message.summary}" detail="#{message.detail}"
severity="#{message.severity}"></message>
</o:messages>
</h:panelGroup>
</messages>
(messages and message are angularJS element directives)
