Blogging Roller

From the Seam Framework team's wiki page on JSF2 major issues:

The JSF2 expert group should work closely with the JSR 311 expert group to define overlapping integration points (unified configuration) and programming models, so that a JSF implementation can work seamlessly with a JAX-RS implementation. For example, a @Path annotated POJO should work as a JSF backing bean without any additional configuration. A JSF application programmer should be able to expose RESTful remote APIs easily.

Right on.

Via Matt Raible

JSF spec lead Ed Burns just pointed out that some of my Sun-internal comments about JSF have made it outside the firewall and into an issue on the JSF specification project:

On Wed, 19 Mar 2008, David M Johnson said:

I think the goal should be to make JSF applications RESTful by default, with proper use of GET and POST, i.e. only use POST when application data is changing, not for component state. Another goal should be clean, book-markable URLs that only carry path-info and parameters needed by the application logic.

That's easy and the default situation with Rails, Grails, Struts, etc. How hard would it be to redesign JSF along those lines? Would it require EJB2 -> EJB3 level changes to JSF?

I suspect work on JSF 2.0 is too far along for this kind of change now, but it's nice to hear that the idea of a truly RESTful JSF is at least under consideration.

I've been very happy with the choice of Struts 2 for Roller, but I still follow JSF because it's the Java standard. A couple of articles by Ryan Lubke about what's coming in JSF 2.0 got me thinking about JSF again.

• Ryan Lubke's Blog: JSF 2.0 New Feature Preview Series, pt. 2.1: Resources
  "Previous versions of JSF had no facility for serving resources"
• Ryan Lubke's Blog: JSF 2.0 New Feature Preview, pt. 1: ProjectStage
  "the JSF 2.0 EG has given a nod to Ruby on Rails' RAILS_ENV functionality"

One of my problems with JSF is REST. REST fans say JSF is inherently RESTless because every JSF request is a POST. JSF advocates say JSF can do GET and bookmarkable URLs if necessary and that's good enough.

• Bill de hora on JSF and REST
  "JSF is clearly not focused on or suitable for working in the REST style to the extent REST principles seem to be actively excluded from the design."
• Gavin King on JSF and REST
  "On these community sites that claim you can't build restful application with JSF. I mean it is total nonsense. It is not even remotely true."
• Gavin's JSF bookmarkable URL example
  In the comments thread of an anti-JSF story at The Server Side.

Fortunately, the plans for JSF 2.0 indicate that REST improvements are coming:

• Java.Net TWik: JSF 2.0 Requirements Scratchpad
  Mentions REST API (JSR-311) and navigation without using POST
• JSR-314: JavaServer Faces 2.0
  "Allow JSF application resources to be accessed via REST" and "Add support for REST (JSR 311)"

Unfortunately, it sounds like all they're planning to do is make it easier to create bookmarkable URLs and add some support for the JSF-311 REST API. Why can't the goal be to make JSF applications RESTful by default? Why can't JSF ensure that POST is only used when required by the application (not the framework) and JSF URLs are simple, clean and always bookmarkable.

Roumen: Visual tools for web development are a double-edged sword. They have their advantages and disadvantages. Some users love Visual Web Pack for what it provides but some of them go crazy because by using visual tools they lose a bit of control or they don't fit their development environment. So I'd like to discuss this topic, so that you can decide whether Visual Web Pack is for you or it is not.

A very thoughtful and balanced post from Netbeans evangelist Roumen Strobl that examines some of the reasons you might or might not want to use the new Netbeans Visual Web Pack.