In a blog entry last year, Ken Paulsen gave a short introduction to the FileStreamer utility in JSFTemplating. Since Scales is now using JSFTemplating to make the component authoring process easier, I have been able to use this facility, allowing me to deprecate some custom code. In the process of making the migration, I’ve made changes to JSFTemplating that will be of benefit to all. In this entry, I’d like to highlight those changes, and show you how you, too, can use this great facility. (more…)

Popularity: 68% [?]

In a recent blog post, Java EE 6 (JSR 316) specification co-lead Roberto Chinnici discussed the two leading proposals for the web profile in the upcoming Java EE 6 specification (For more information about profiles, one can start with this article on TheServerSide.) The part that caught me by surprise and confuses me greatly is why the inclusion of JavaServer Faces in the web profile would be controversial. Having spoken with an expert group member, who I will not out :), the argument comes down to this: “We shouldn’t force a broken technology, that is not the clear winner on people.” I think that’s a very interesting statement, in that it precludes doing just about anything in the spec. (more…)

Popularity: 67% [?]

At the lunch session of the OKC JUG today, a question was asked about the difference between the valueChangeListener attribute and <f:valueChangeListener/>. That is,

<h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}" valueChangeListener="#{optionBean.optionChanged}" onchange="submit()"> <f:selectItems value="#{optionBean.optionList}" /> </h:selectOneMenu>

and

<h:selectOneMenu id="optionMenu" value="#{optionBean.selectedOption}" onchange="submit()"> <f:selectItems value="#{optionBean.optionList}" /> <f:valueChangeListener type="com.mycompany.MyValueChangeListenerImpl" /> </h:selectOneMenu>

The question was, which is “better?” There was also a question if the latter form automatically handled the JS on the parent component. I will now attempt to answer those questions now.
(more…)

Popularity: 82% [?]

One of my long-standing complaints with Ant is that project dependency management is non-existent in the core Ant distribution. Many will quickly point to the Maven Ant tasks, but I’ve never been really fond of them for one reason or another. The other advice I often get is to use Ivy, but even after several attempts, I had never gotten Ivy to work. With the recent release of 2.0 beta 1, though, I thought I’d try again, and I’m glad I did. Not only have I gotten it to work for me, but I was also able to successfully configure custom resolvers. Below is what I had to do to migrate the Mojarra Scales dependency management to Ivy. (more…)

Popularity: 100% [?]

In my last post, I alluded to some refactoring done inside the Sandbox/Scales library to simplify the components’ code. If you are interested in learning more about what was done, and how you can apply the same techniques to your own JSF components, please see this article, written by Ken Paulsen and myself, with editing help from Rick Palkovic, which shows how one can use JSFTemplating and some (currently “private”) annotations from the Woodstock project to greatly simplify JSF component authoring. I think it’s a very interesting and helpful technique, which, by the way, resembles what JSF 2 will likely offer when we finally ship it later this year.

Oh, yeah. Happy New Year’s!

Popularity: 69% [?]

Some of you may be wondering what the status is on the RI Sandbox. With the announcement of Project Mojarra, we can finally take the wraps off of Mojarra Scales, the promotion of the RI/Mojarra Sandbox to its own project. (more…)

Popularity: 74% [?]

It is with a pretty high degree of excitement that we, the JSF RI Mojarra development team, announce Project Mojarra. While the project itself is not new (it’s the same, high quality and stable JSF implementation we’re all familiar with ;), the announcement of the new moniker brings to an end a lengthy, and sometimes frustrating, process of deciding on a name that can pass legal muster. For more details on the name change, see this entry by Ryan Lubke.

Popularity: 62% [?]

Well, that wasn’t hard. I think I have the redeploy issue fixed, and a shared library was the trick. (more…)

Popularity: 79% [?]

As a follow-up to my entry on getting a Seam and JPA/Hibernate application running on OC4J, I now have an alpha release of a Maven 2 archetype available for use and testing, with heavy emphasis on testing. (more…)

Popularity: 86% [?]

On a recent project, the architecture we settled on included JavaServer Faces (no surprise, there, I guess:), JBoss Seam and JPA. The production environment is Oracle’s OC4J, so the stack we chose has to deploy (easily) to that container. While I did get it working, it wasn’t easy, nor was it easily reproducible. Now that the pressures of deadlines have passed, I took the time to track down what exactly needs to be done to make the application deploy and run on OC4J. In retrospect, it doesn’t look that hard, but, knowing the pain I went through to make it work, I thought I’d share what you need to know if you’re in a similar situation. (more…)

Popularity: 69% [?]