Paul Dijou - Paul Dijou

News about RichFaces CDK

Posted by on Aug 01, 2012 Comments Improve this article

RichFaces CDK new features

As the RichFaces Bootstrap project grows, we need more tools to achieve new goals and keep the code clean and readable. More tools means a stronger CDK and here are the last features.

Fragments are small portions of code inside the template that are defined outside of the main implementation but can be called inside it or inside other fragments or even inside itself! Say hello to recursion in RichFaces CDK templates. In term of Java, fragments are methods. So when you write a fragment, it will generates a Java method in the final renderer. Knowing that makes fragments really easy to understand and to use. See the JIRA issue 12226 for a fully explained example.

Pro tip Notice that in the signature of the generated Java method, 3 arguments are always passed without having to specify them inside the template : ResponseWriter, FacesContext and UIComponent.

Warning Currently, if you want to use a fragment1 inside a fragment2, you need to write fragment1 first in your template so its signature has been parsed before calling it in fragment2. Problem is reported in JIRA issue 12326.

cc:renderFacet is a new tag you can use inside a CDK template, equivalent of the same tag from JSF composite component. Its usage is quite straightforward: it will render the facet that you will specify in the name attribute. If you put some content inside the tag, it will be used as default value in case the facet is missing. See JIRA issue 12260 for full description.

varStatus is a new attribute for the c:forEach CDK tag. It will perform the exact same thing as the one in the original c:forEach tag, giving you more tools inside a forEach loop. See JIRA issue 12232.

wildcard can now be used inside cdk:passThrough and cdk:passThroughWithExclusions attributes in order to pass all attributes starting with the same prefix. Especially useful with JavaScript events on*. Wildcard can be use with attribute mapping like onkey*:oninputkey*. See JIRA issue 12200.

component variable is now directly casted to the correct class based on cdk:class tag in the template. You will no longer need to write explicitly the cast inside 95% of your templates. Enjoy less verbose code and see JIRA issue 12248 for more details.

In general, CDK has been improved to be more type-safe which allows to catch more issues at compilte-time.

What’s next?

There are still a few points undone in the CDK wish-list and I hope some of them will be realized. One of the most important is probably generating methods from interfaces! See JIRA issue 12339 to fully understand the concept.

In another topic, another post will follow next week to talk about what’s new in RichFaces Bootstrap project.

JSF, Bootstrap and calling render=@all

Posted by on May 08, 2012 Comments Improve this article

The problem

So, the other day, I was playing with Twitter Bootstrap on a JSF application. Everything was fine until I decide to use a render="@all" somewhere in the page in order to refresh all my components after quite an heavy operation. Working fine.

But Bootstrap was no longer fully healthy. The CSS and design were ok, but the JavaScript was all broken : nearly all effects didn’t appear anymore. It was a bit strange so I hit F5 and everything was fine, all JavaScript events were back. But the moment my render="@all" was called, they disappear again.

Why?

After some investigations, the reason was that Bootstrap calls a JavaScript function that will attach most of its events to the <body> when the HTML DOM is ready. Its doing so in order to catch all user interactions when they bubble up to the <body> tag which wrap the whole page. With that, you can use Ajax as much as you want and update your DOM since there is no event attach to a particular HTML tag, they are all in the <body> tag.

That’s really good but that’s also the reason of the problem. I said Ajax is always fine, and it’s true as long as you don’t touch the @<body>@ tag. The moment you update this tag, it will probably be reset to it’s initial state, without any JavaScript event, and since the Bootstrap JavaScript function is only called once when the DOM is ready the first time, JavaScript events will not come back. Guess what, render="@all" will render your <h:body> and so will broke all Bootstrap JavaScript events.

A workaround

The true solution would be to call the Bootstrap JavaScript function after each render="@all" in order to attach all JavaScript events again. But since I have no idea how to do that right now, I have chosen to use an easier workaround.

Just wrapping your whole page in a JSF panel and render it instead of render="@all" should be enough in most use case. It is not exactly the same behaviour, but in most case, when calling render="@all", what you really want is just refreshing your whole page using Ajax. For example:

<!DOCTYPE html>
<html lang="en-US"
      xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://java.sun.com/jsf/html"
      xmlns:f="http://java.sun.com/jsf/core"
      xmlns:ui="http://java.sun.com/jsf/facelets">
<h:head>
    <title>Site title</title>
</h:head>
<h:body>
    <h:panelGroup id="all">
        ... your code...
    </h:panelGroup>
</h:body>
</html>

And replace all your render="@all" with render="all".