Who are your visitors? Consider the example where you and I work for a technology company attempting to sell solutions to customers on the web. Our homepage is currently cluttered, and we’re not seeing the conversion numbers that we would like. One of our colleagues has suggested that in order to improve adoption of your products, an architecture diagram with links to various solutions be placed on the splash, or landing page of the company website. It shows a great many products, and how they are all related, but there is not a great deal of immediate information on how to get started with any given topic. This will be the first thing new visitors see when they come looking for… what was I looking for again? There are categorically two kinds of people who visit a website, we will refer to these as group one, and group two:

1. People who know what they are looking for.
2. People who have no idea what they are looking for.

Let’s consider the impacts of this impression.

Which of our two groups of people would benefit from an architecture chart (such as the one your colleague suggested?) That’s right, you guessed it; those people are in group number one. They already know what their architecture is going to look like roughly, or know enough to realize they need to do some architecture research and are looking for a specific solution. They may already even be a customer and are simply coming back to the website to find more information about a product they are already using – looking for a user-guide or perhaps the service-desk phone number. Congratulations! You have successfully provided little no value to these users, because you force them to look at a page of marginally information before they can get to what they really want, after digging through a series of links or buttons; we really should have just shown them the information they wanted in the first place, without the little overview of… everything. So what about our second group? Surely everyone else who falls in to group number two must surely benefit from seeing a pretty diagram of all our products laid out in front of them? If we show them everything, they’ll surely be interested in at least one of our goodies, right? Wrong…

Do you have an existing Maven-based Java EE application that you’d like to clean up a bit in the browser? Do your URLs look too much like this: http://example.com/app/sillyServletName/someStuff?sillyParam=22&sillyOtherParam=profile And not enough like this? http://example.com/app/profile/22 Are you building a new application, and don’t want to sacrifice anything when it comes to usability or SEO capabilities? Well, URL-rewriting is your answer, and it’s easy to get started, even easier using JBoss Forge.

I was recently asked the question, “Is it possible to create a modular JSF application, where JAR-files act as plug-ins and allow xhtml views, images, css, navigation rules, and managed beans to be added as modules to the application?” The answer to this question is, “of course,” but there is no pre-set way of accomplishing such a task, so you’ll have to be a little creative. I’ve come up with a conceptual architecture that “would work,” if properly implemented, but keep in mind that this is just something I threw together in a few minutes of thinking about the problem.

A recent thread came up on the JSF 2 forums: “Why can’t I use @Inject in a PhaseListener? This CDI stuff is so confusing.” FIrst, before I start explaining: this is possible, but there’s a little background you should probably know. The answer to the question “why can’t I use CDI in JSF PhaseListeners?” is: because JSF 2 was completed just a few short months before JSR-299 and the rest of the Java EE 6 platform specifications were finalized. In my opinion – because of the current state-of-affairs in the JCP – it was just not a safe bet to promise integration with other technologies that might not have been finalized in time. Fortunately, however, JSF goes to extra lengths in providing extension points – solving this with an extension was not too difficult.

So Java EE 6 is out, and you’ve decided to give it a go. You’re trying to port an existing application over to the new stack (or are trying to create a new one for the first time,) but exceptions are bursting through the seams and you just can’t seem to get things to work. If you’re familiar with Spring and Hibernate (with all the joy that is OpenSessionInView or OpenSessionInConversation,) more than likely the problems you’re having are related to the Java Persistence API (JPA), combined with Enterprise Java Beans (EJB). Contexts and Dependency Injection (CDI) should be a familiar face if coming from Spring, but things are subtly different in the world of Java EE.

“The problem is not the system, its the way someone can get in. To be honest, most tutorials, how-tos, and documentation sucks, because they ALL are written like the reader already knows the trick. No doc about [Technology] is written for newbies.”

Here’s a simple tip for all of you AJAX lovers using JSF 2.0. It is possible to render components that live outside of the form where your AJAX tag lives; actually, it’s possible to render any component by using it’s fully-qualified component ID. Just prefix the target ID with the naming-container separator character, usually “:”, and provide the full name of the component as it is rendered on the HTML page.

We’d like to take a moment to introduce you to the OcpSoft Support Forums. These forums will serve as an alternative to the existing User’s Group mailing lists for PrettyFaces, PrettyTime, and SocialPM.

I’d like to start by saying that using JSF by itself can sometimes feel trying to pull your own teeth out with a pair of tweezers, but there’s hope. JSF was designed to be a platform of extensions – a foundation for building web-frameworks, and that it’s done very well. JSF 2.0 addresses most of the concerns about usability (so there’s less tooth pulling,) and provides even more extensibility. That’s where Seam Faces comes in, that’s where PrettyFaces comes in. On many occasions you might find yourself needing to compare the values of multiple input fields on a given page submit: confirming a password; re-enter password; address lookups; and so on. Performing cross-field form validation is simple – just place Seam’s <s:validateForm> component in the form you wish to validate, then attach your custom Validator.

Ever wondered why JSF doesn’t support bean @Inject-ion in Converters or Validators? Ever wondered how to listen to a single PhaseEvent or ComponentSystemEvent, or filter on events by componentId, or view? Ever wondered why you can’t just @Inject FacesContext, or NavigationHandler?

Well… now you can, with the brand-new, just-out release of Seam Faces — 3.0.0.Alpha3