Jacob Hookom's Blog: July 2005 Archive

I was a JavaOne virgin; I didn't know what to expect. I had been contributing to the JavaServer Faces specification and the reference implementation for quite some time, but was looking forward to finally meeting everyone involved in person. Tell you what, the folks from Sun are some of the nicest people I've ever met professionally.

I made a point to try to make it to sessions that I felt would most apply to my job (including JBI), but often times I ended up wandering over to the web framework presentations. It's no wonder why they spark so much interest and debate as it's the keystone to your application's stack-- where everything is finally orchestrated and labeled as a finished product.

I'm probably digressing a bit, because I would like to talk about JavaServer Faces and how it's evolving. I was really dissapointed to read David Geary's blog, where he mentions being a contributing expert on the original JSF specification, and in the same entry put JSF off as overly vendor oriented as if the framework didn't 'get it right'. I think his blog failed to mention all the opportunity within JSF (although he wrote he would blog more on the topic). Thousands of people attended JavaServer Faces-related presentations at JavaOne and the reason is the potential that the platform provides. AJAX (sorry Dan), alternate view technologies, toolability, controller options such as Shale or Spring MVC, and specialized components just to name a few.

I keep on referring to JavaServer Faces as a platform. Anyone that attened Kito Mann's BOF at JavaOne, the guy went on for an hour with all of the options and additions that you can use with JSF. People compare JSF to Tapestry, Ruby on Rails, Spring, and Struts, but the clear point for everyone is that the JSF platform could use any of the aforementioned technologies or replicate their capabilities.

I gave a presentation last June in Minneapolis on the web tier alignment (which I will get to ;-)), but I emphasised the possiblities that developers could take and run with. Right now you could tie in Spring on numerous levels within JSF, you could easily develop EJB3-backed components to give you Ruby on Rails 'scaffolding' functionality, you can integrate Shale into your development for extended controller functionality, or you could start using JSF with frameworks like Facelets for Tapestry-like features.

One of the major events to occur for JEE 5, was the web-tier alignment between JSP, EL, and JSF. Some of the features to come from this alignment are:

EL Resolution
This really takes the cake. The new EL spec allows you to chain (via composition), resolution for both variables and properties. You could chain variable resolution with Spring along side your own backing-bean framework, and then add a special property resolver within EL for handling custom domain model objects.
Variable Scopes
It seemed to me that a majority of issues posted for JSF came from JSP use. Within JEE 5, JSP and JSF will share the same variable context (mentioned above) so 'things will work' as everyone expects them to through rendering and building component trees.
JSTL Use
Now piggy-backing the EL specification, things like <c:forEach/> will now work in conjunction with JSF component tags. A new version of JSTL is being rev'ed up to accomodate JSF, but to those familiar to JSTL, you won't be seeing any change since it's all under the covers of the JSP tags.
JSE 5 Support
While it's still on the table as to how it will be used in certain parts of JEE 5, it wouldn't take a rocket scientist to be able to add annotation support to UIComponents in order to 'automate' state management and rendering for you.
Anything Else?
JSP 2.1 and JSF 1.2 made lots of other enhancements to their specifications, but I simply wanted to bullet JEE 5's committment to making things easier for developers while opening a flood gate of possibilities as a platform.

Where do you go from here? Well there's a couple options available to you depending on your needs as a developer and your project deadlines:

Start Using JEE 5 Now
Java.net's Glassfish project offers you great opportunity to start using JSF 1.2 and JSP 2.1, along with the rest of the JEE 5 stack. The developers working on Glassfish are the same folks that contributed to the wildly popular Tomcat container. For those that are looking for an easy to use container, the Glassfish web-based administrative console is both beautiful and simple to navigate.
- Getting started is just as easy as with Tomcat, read more here on getting your first war deployed.
- Glassfish developers answer questions in minutes (it's ridiculous) and you can join the mailing lists here to get immediate support.
Try Facelets
There was a lot of great work done to correct issues between JSP and JSF and for those that can't rev up to JEE 5 any time soon, then Facelets will offer you the same advantages in the web-tier. Facelets will work with both the JSF RI and Apache MyFaces while allowing you to start using JSF 1.2. The framework is founded on making things easy for the developer and comes with templating features and EL support.
- Lots of documentation is here, which gives you a taste of the templating and Tapestry-like features.
- Facelets includes a 'developer' mode which takes some of the black-box issues away with screens like this.
- Lastly, I've gotten great feedback from folks such as Mike Kienenberger, Matthias Weßendorf, and Bing Ran-- please join the mailing lists and get involved in this new technology! Mike already proved how easy it is to get custom components integrated in Facelets without any extra coding.

Programmer Friendly Pages

Posted by jhook on July 27, 2005 at 12:40 AM | Permalink | Comments (4)

Let's first start by talking about development roles and concerns. MVC has taught us how to separate our application into managable layers. We have the Model and Controller which are under the programmer's ownership, then we have the View which is under both the programmer's and designer's ownership. This is where issues arise as both the programmer and the designer wish to implement their concerns in the cleanest way possible within the same document or page.

Your programmers' goals are to provide structure and data to web pages; really they shouldn't care how the data is presented, only that it's there and functions within the application requirements. The designers' goals are to properly present information in a meaningful manner and should not concern themselves with knowing any server technologies such as tag libraries or the application's Java model.

Semantic contracts are the key. This is as simple as agreeing on ways of structuring the menu or providing a specific attribute such as an 'id' or 'class' in the rendered output. Unless you've been hiding from the web for the past few years, you know I'm hinting at using Cascading Style Sheets (CSS) and externalizing JavaScript behavior.

Early in the development process, designers and programmers can agree on how the documents are structured and what ids and classes are expected. These discussions will probably continue throughout the development process, but the point is to allow a degree of separation such that the programmer is no longer reliant on the designer to publish their data into documents.

If I were ask you to program the domain model for a large project, you would probably approach the problem using object oriented principles, emphasising reuse and maintainability. Now apply that same programmer mindset to developing your views with components. Let the designer mock up their own pages for developing the common CSS and JavaScript resources.

As long as the contract stays in place, the programmer can write highly reusable JSF components that aren't tied at all to the concept of a page. In some cases it might be ultimately faster to deliver the XML content right from Java code. After all, you are no longer attempting to cater to the designer's tools and you are still meeting the semantic contract everyone agreed upon.

With CSS use, the required markup becomes much lighter. This only encourages taking the ideal case for a programmer to be able to compose components that deliver huge amounts of data in a highly efficient and maintainable manner. At the same time, the programmer caters to the designer by providing CSS attributes on their components, such as id, class, and style.

You can deploy your component and use it in multiple places and the designer can, at any time into development or production, change the way your component looks on the page (or behaves in some cases) because of CSS and JavaScript standards.

In summary, programmers should be able to get the 'traditional' need for page-based development out of their heads. There's always middle ground for efficiency in projects, but after you find yourself maintaining forty or fifty pages and their associated actions in MVC 2, you will probably be looking for better methodologies. Having the designers and programmers agree on semantics early in the project opens up a lot of flexability in delivering maintainable solutions for both parties.

Here's a (sample) list of popular web sites that are using these new standards:

Powered by
Movable Type 3.01D

java.net RSS Feeds