Dave Johnson on open web technologies, social software and software development
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.
Via Matt Raible
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.
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.
Fortunately, the plans for JSF 2.0 indicate that REST improvements are coming:
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.