JavaServer Faces is a powerful framework, but it doesn't cover some important areas of a web application (or web site) - at least, not natively. However, its great extensibility gives us the ability to work around many of its apparent limitations. One of the limitations is bookmarking. JSF uses POST to send data to the framework from the client browser; clearly this is a barrier to bookmarking and indexing, both of which are very important for content applications, where users should expect to be able to bookmark articles or references, for example. Many frameworks extending JSF try to fill this void: Seam, Shale, Gravel, RI Sandbox and RestFaces. The latest RestFaces snapshot release (documentation)provides the following benefits:

• Invocation of actions using simple GET requests (in the same way as Struts or Spring MVC),
• Setting bean properties before action invocation, again using GET parameters. In this way actions can correctly read the parameter's value and save their state with the bean.
• Automatic management of parameters in links: it can even auto-append parameters if you want.
• Conditional execution of methods listening on page load events (for example it can execute an action just before the "page.jsp" is rendered).

For the most complex features, like parameter management, RestFaces requires an xml file, but it's not generally mandatory. Recent developments make it possible to define actions and property management directly in the page (provided you're using JSP or Facelets). RestFaces can reload the configuration if it detects the xml has been modified, to support hot redeployment. We paid attention to security, too: URLs can't be meaningfully edited by malicious users. For example, they can't manipulate URLs causing RestFaces to call insecure methods and or corrupt the server state.

RestFaces does his job very well, all JSF applications can handle GET request easily without much work. If you can't wait JSF 2.0 to handle this feature, then RestFaces can be a good option.

Many frameworks extending JSF try to fill this void: Seam, Shale, Gravel, RI Sandbox and RestFaces."

Since this is the case, are there features unique to RestFaces?

Many frameworks extending JSF try to fill this void: Seam, Shale, Gravel, RI Sandbox and RestFaces."

Since this is the case, are there features unique to RestFaces?

Maybe only some minor features like the ability to encrypt URL. I think most of the RestFaces features about bookmarking are also in Seam. So if you are using Seam I don't think you need to improve this aspect. But, you know, Seam has strong requirements (EJB), and is not a very simple framework (but it is very nice!). Otherwise you can't obtain all the RestFaces abilities using the other 3 libraries. Expecially parameter management is not in Shale, Gravel or Sandbox.

...Seam has strong requirements (EJB)...

This is not true any more http://www.michaelyuan.com/blog/2006/11/14/seam-without-ejb3/

Does it work transparently in a portlets environment? For example in a JSF Portlet in Liferay? Thanks, Alberto.

Does it work transparently in a portlets environment? For example in a JSF Portlet in Liferay?

Thanks, Alberto.

I dunno much about Portlets. I remeber there are maybe 1 point of the code where I cast to HttpServletResponse, that AFAIK should raise an error in a portlet environment, shouldn't it? Anyway this method is for displaying the RestFaces error page (not very usefull expecially in production). So, as far as JSF support portlets, RestFaces should support it too. Can you try, and post an issue in case of unsuccess?

I do not see any reason whatsoever to use REST in the name of this library. It gives obscure RPC-style web framework an ability to perform operations with GET requests. It does not make it RESTfull by any means. I guess, it even breaks one of the most fundamental requirements for RESTfull applications - safety and idempotence of any GET request. I mean the careless developer has a real chance to give away URLs which change the state of the resources on every hit. And here is the qoute from site:

RESTFull application offers feature like bookmarking and indexing, two very important aspects for a web site.

Are you taking a laugh? Have you read Wikipedia REST page by any chance? Is it really about very important features for a web site or RESTfull application?

I agree, there is NOTHING in RestFaces that could be considered "RESTful". JBoss Seam makes a similar claim http://docs.jboss.com/seam/latest/reference/en/html/tutorial.html#blog It's sad that the term REST is being so misused in the Java presentation space Ryan- http://damnhandy.com

It's sad that the term REST is being so misused in the Java presentation space

I agree with you guys that there are difficulties in applying REST to JSF. The main issue is that HTML only supports two HTTP methods, so by design HTML applications can only use a subset of the uniform interface. I agree that using GET to change server state is risky to I try to stay away from this approach. GET should be safe and idempotent:

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

JSF correctly uses POST for form submission. Some developers feel this is a limitation and try to find ways to invoke action methods via GET, which violates the HTTP spec. Bookmarking is easy to implement in JSF! You can use pull-style MVC to load data (via getter methods on your backing beans) in a RESTful way: HTTP URI: /products/index.jsf?product=12345 JSF Code (/products/index.jsf): Backing Bean: public class ProductBean { public Product getProduct() { FacesContext ctx = FacesContext.getCurrentInstance(); ExternalContext external = ctx.getExternalContext(); HttpServletRequest req = (HttpServletRequest) external.getRequest(); String productId = req.getParameter("product"); return entityManager.find(Product.class, productId); } } It just takes some careful thought and you can design your JSF applications in a RESTful way. Backing beans can easily become URI-addressable resources that use GET and POST as intended. What's great about JSF is how easy it is to bind UI components to backing bean methods, so you get this powerful abstraction layer that allows you call any Java method from your user interface. It's up to the developer to use this power responsibly. Ian Hlavats JSFToolbox for Dreamweaver

I agree that using GET to change server state is risky to I try to stay away from this approach. GET should be safe and idempotent.

And calling an action doesn't mean I am performing and update or an insert. It doesn't mean it is not idempotent.

JSF correctly uses POST for form submission. Some developers feel this is a limitation and try to find ways to invoke action methods via GET, which violates the HTTP spec.

I don't think so. In fact JSF 2.0 will recognize the bookmarking problem and will try to solve it. Use GET requests when you can use them!

Bookmarking is easy to implement in JSF!

It is surely possible, but not easily and immediatly.

Backing Bean:
public class ProductBean {

public Product getProduct() {
FacesContext ctx = FacesContext.getCurrentInstance();
ExternalContext external = ctx.getExternalContext();
HttpServletRequest req = (HttpServletRequest) external.getRequest();
String productId = req.getParameter("product");
return entityManager.find(Product.class, productId);
}

}

This code is not smart. Business logic should never stay in getters. And your example is also incorrect: getters could be called more then one time per JSF request, causing multiple query to be performed unnecessarily. Really this is not the way to go.

calling an action doesn't mean I am performing and update or an insert. It doesn't mean it is not idempotent.

Hi Alfredo, Calling a business method (as JSF actions usually do) is much more likely to change state than calling a getter.

Use GET requests when you can use them!

Use GET whenever you can? Is that a RESTful approach? Sorry Alberto, what are your sources? The W3C has some relevant information on the correct use of GET and POST:

1.3 Quick Checklist for Choosing HTTP GET or POST * Use GET if: o The interaction is more like a question (i.e., it is a safe operation such as a query, read operation, or lookup). * Use POST if: o The interaction is more like an order, or o The interaction changes the state of the resource in a way that the user would perceive (e.g., a subscription to a service), or o The user be held accountable for the results of the interaction.

There it is. GET should be used for safe operations, like a query. Sure, you can use GET to invoke safe action methods, but isn't that like squeezing square pegs into round holes? I mean, not only are you risking state changes with GET, but now you're treating JSF action methods as safe/idempotent too?

Bookmarking is easy to implement in JSF!

It is surely possible, but not easily and immediatly.

I strongly disagree. I have 10+ years in web design, don't tell me bookmarking is hard to support. If you are inexperienced in information architecture and navigation design, then sure it can be challenging. You can always hire a web designer or SEO consultant to do a usability assessment on your project. You may also want to read something from Jakob Nielsen or Edward Tufte, two experts in the fields of web usability and information design.

public class ProductBean {

public Product getProduct() {
FacesContext ctx = FacesContext.getCurrentInstance();
ExternalContext external = ctx.getExternalContext();
HttpServletRequest req = (HttpServletRequest) external.getRequest();
String productId = req.getParameter("product");
return entityManager.find(Product.class, productId);
}

}This code is not smart. Business logic should never stay in getters.
And your example is also incorrect: getters could be called more then one time per JSF request, causing multiple query to be performed unnecessarily.
Really this is not the way to go.

Yawn. Business logic should never stay in getters? I disagree. What about calculations? Validation? Business logic? Examples: - shoppingCartBean.getTotalWithShipping() - customerOrder.isValidCreditCard() - etc. My example was glorified pseudocode. Ok, let's make it more robust. I use Seam so my backing beans are actually session-scoped SFSBs, ideal for managing client state across requests. Here's how I would do it in production: @Stateful @Name("productBean") @Scope(ScopeType.SESSION) public class MyStatefulSessionBean extends AbstractStatefulSessionBean implements MyBusinessInterface { private Product product; public Product getProduct() { try { // GET: lazy-load the product (1) if (this.product == null) { FacesContext ctx = FacesContext.getCurrentInstance(); ExternalContext external = ctx.getExternalContext(); HttpServletRequest req = (HttpServletRequest) external.getRequest(); String productId = req.getParameter("product"); this.product = entityManager.find(Product.class, productId); } else { // make sure detached entity is managed (2) if (this.product != null && this.product.getVersion() != null) { if (!entityManager.contains(product)) { String id = this.product.getId(); this.product = entityManager.find(Product.class, id); } } } } catch (Exception e) { logger.error("Couldn't get product:", e); } return this.product; } public void saveProduct(ActionEvent event) { try { if (this.product != null) { // POST: save the product (3) entityManager.persist(product); // reset the bean state (4) reset(); FacesContext ctx = FacesContext.getCurrentInstance(); ExternalContext external = ctx.getExternalContext(); HttpServletResponse response = (HttpServletResponse) external.getResponse(); // redirect to the current view (5) if (!response.isCommitted()) { UIViewRoot view = ctx.getViewRoot(); String viewId = view.getViewId(); String uri = viewId + "?product=" + product.getId(); response.sendRedirect(uri); ctx.responseComplete(); } } } catch (Exception e) { logger.info("Couldn't save product:", e); } } /** * This method should be called when state changes * and a refresh of cached data is needed. */ public void reset() { this.product = null; } } A quick explanation: (1) In the getProduct() method, we check to see if the product is null (if so, we load it - one database query per request). This method is called using HTTP GET. (2) If the product is not null (already loaded), we check to see if the entity is managed by the persistence context (if not, we simply reload it make sure we have the latest data). (3) We handle a form submission (ActionListener event) in our business method and save the product. This method is called using HTTP POST. (4) We reset the state of the bean to ensure data is re-loaded on the next request. (5) We send a redirect to the browser (Post-Redirect-Get pattern) to avoid the double-submit problem, back button problems, etc. We also append the product ID to the querystring to reload the current product. You could improve the code further by refactoring the FacesContext and EntityManager API calls into inherited superclass methods, but this is the basic pattern I use in managing conversational state in JSF while using GET and POST for their respective purposes. Regards, Ian

Use GET whenever you can? Is that a RESTful approach? Sorry Alberto, what are your sources?

The W3C has some relevant information [CUT]

That is exactly what I meat: use GET when you should use them.

GET should be used for safe operations, like a query.

Sure, you can use GET to invoke safe action methods, but isn't that like squeezing square pegs into round holes?

I mean, not only are you risking state changes with GET, but now you're treating JSF action methods as safe/idempotent too?

Probably you didn't understand what RestFaces does. Why do you go on calling them "JSF action methods"? They are plain methods invoked by EL, not JSF methods. You can put whatever you want inside them. The programmer has the responsability of write the right code, not the framework.

I have 10+ years in web design, don't tell me bookmarking is hard to support.

Do you have 10+ year of experience of bookmarking in JSF? Strange, I didn't know it was older then Struts, for example.

Business logic should never stay in getters?

I disagree.

What about calculations? Validation? Business logic?

Are you joking? Accessing a database is different from executing very simple logic like validations etc... An MVC rule says that you should put into them only very simple logic. I think it is not the case of your code. if (product == null) { //execute SQL } etc.. but this is an hack. The if and also reset(); are necessary beucase you choice a not very smart code. Are you using Seam? You can do much better: give a look at its documentation and you'll find an excellent support for REST-style programming. Seam too, felt the need for an improved bookmarking support. Again also JSF2.0 is trying to improve JSF in this area. But all them (JSF2, RestFaces, Seam etc..) are surely doing an unnecessary work. Regards, Alberto Gori (not Alfredo please).

Probably you didn't understand what RestFaces does. Why do you go on calling them
"JSF action methods"? They are plain methods invoked by EL, not JSF methods. You can put whatever you want inside them. The programmer
has the responsability of write the right code, not the framework.

Hi Alberto, Your framework certainly has some interesting features. I think the concern being expressed here is the potential for abuse of the GET method (by allow it to invoke JSF action methods). Why do I call them JSF action methods? Because they conform to a particular signature expected by the JSF framework. Also, they are typically called by UICommand components during form submission via POST. JSF action methods are syntactically and semantically different from getter and setter methods. Action methods are designed to influence controller behavior (changing views, updating the model, etc.). I'm sure you're aware that getter/setter methods are called during the Render Response and Update Model Values lifecycle phases, while action methods, action listener methods, value change listener methods, etc. are called during the Invoke Application phase. So why do not understand the term 'JSF action method'? The JSF 1.1 API states that an action method "must be public, with a return type of String, and accept no parameters."

I have 10+ years in web design,
don't tell me bookmarking is hard to support.

Do you have 10+ year of experience of bookmarking in JSF? Strange, I didn't know it was older then Struts, for example.

Ok, I guess you missed the point. I'm trying to say that by following basic web usability guidelines you can make your JSF application bookmarkable. It just takes some thinking about how your hyperlinks will be structured. Does plain JSF support this? Sure. Just use h:outputLink and f:param.

Business logic should never stay in getters?

I disagree.

What about calculations? Validation? Business logic?

Are you joking?
Accessing a database is different from executing very simple logic like validations etc...
An MVC rule says that you should put into them only very simple logic. I think it is not the case of your code.

Once again, what is your source? Where is your information coming from? There is nothing wrong with accessing a database from a stateful session bean. That's what EJBs are designed to do. Have you read Martin Fowler's article on the anemic domain model anti-pattern? It is acceptable to put non-trivial business logic in a getter method.

It's also worth emphasizing that putting behavior into the domain objects should not contradict the solid approach of using layering to separate domain logic from such things as persistence and presentation responsibilities. The logic that should be in a domain object is domain logic - validations, calculations, business rules - whatever you like to call it.

My SFSB is a controller, not part of the model. Therefore persistence and presentation is still separate from domain logic (i.e. code that goes in the Product class). The Seam blog example demonstrates the pull-style MVC approach. They use the same technique (loading data in the getter method of a session bean). So writing an if statement is "not smart code"? There is nothing wrong with an if statement. It adds robustness by checking for cached data before querying the database. You may want to review the Sun's Java BluePrints. My approach is consistent with the MVC design pattern - the view is allowed to query the model (i.e. during the Render Response phase). Good luck with your project, Ian

Why do I call them JSF action methods? Because they conform to a particular signature expected by the JSF framework. Also, they are typically called by UICommand components during form submission via POST.

JSF action methods are syntactically and semantically different from getter and setter methods.

Sorry, but can you suggest a better signature? I don't need parameters and the returned string can change the displayed page. I don't see anything wrong with this signature. Are you really only complaining because this signature is the same of a UICommand action? This seems to me a weak argumentation. A restfaces programmer will use rest:link when wants to make an operation bookmarkable. This is enough to protect him fr om every abuse. If one downloads restfaces without knowing this simple rule, it is his business.

It just takes some thinking about how your hyperlinks will be structured. Does plain JSF support this? Sure. Just use h:outputLink and f:param.

Sure, but rest:link + f:param do much more. For example f:param doens't have any conversion. RestFaces can use converters instead. f:param are not normally auto appended. RestFaces can do it instead, etc.

Business logic should never stay in getters? I disagree.

You argumentation is good. Anyway I continue to dislike this style. For example, in a normal JSF POST a get could be called also before the action is executed, for every reason (it is in a inputText and JSF need to validate or convert the value). It is still ok that it is executed in that point of the lifecycle? Maybe or maybe not. It overcomplicates the code, and could introduce obscure bugs. I prefer an explicit method instead, that will never be invoked in a different point of the lifecycle. Another important point: what happen if you have a commandLink that post to the same page? After the post the parameter is null, the getter is executed and this could be a problem! Instead an action style programming avoids this 2 issues. RestFaces anyway helps also the other programming style ("view" elements).

Sorry, but can you suggest a better signature? I don't need parameters and the returned string can change the displayed page. I don't see anything wrong with this signature.

I didn't realize your EL resolver looks for methods that have the same signature as JSF action methods. This might be a source of confusion for other developers too. Perhaps you could define a new event type: public void search(GetEvent event); Also I would be very clear in your API about not changing state while handling the event. Personally I would still use the Post-Redirect-Get pattern and have a the controller redirect the browser to a view that displays the search results with the querystring containing all the necessary parameters to reconstruct the view. Hopefully JSF 2.0 will allow form GET submissions, because it makes sense to use GET when the action does not change state:

The "get" method should be used when the form is idempotent (i.e., causes no side-effects). Many database searches have no visible side-effects and make ideal applications for the "get" method. (Source: W3C)

Does plain JSF support this? Sure. Just use h:outputLink and f:param.

Sure, but rest:link + f:param do much more. For example f:param doens't have any conversion. RestFaces can use converters instead. f:param are not normally auto appended. RestFaces can do it instead, etc.

This could be your value proposition. Tags that simplify common tasks are useful.

Business logic should never stay in getters? I disagree.

Anyway I continue to dislike this style. For example, in a normal JSF POST a get could be called also before the action is executed, for every reason (it is in a inputText and JSF need to validate or convert the value). It is still ok that it is executed in that point of the lifecycle? Maybe or maybe not.
It overcomplicates the code, and could introduce obscure bugs.
I prefer an explicit method instead, that will never be invoked in a different point of the lifecycle.

I have not run into any issues with this approach. Actually it works very well for me. You can always add robustness by checking for nulls, handling exceptions, etc. This can continue to be refactored into superclass methods to keep the code simpler and easier to read.

Another important point: what happen if you have a commandLink that post to the same page? After the post the parameter is null, the getter is executed and this could be a problem!

In reality, I initialize the product if it is null before the method returns (e.g. in a finally block).

Perhaps you could define a new event type:

public void search(GetEvent event);

Ok, It could be a good idea to support also this apprach. GetEvent probably would make available the passed parameters. Anyway I should see how this apprach integrates with other features (for example auto append parameters feature).

Also I would be very clear in your API about not changing state while handling the event.

Personally I would still use the Post-Redirect-Get pattern and have a the controller redirect the browser to a view that displays the search results with the querystring containing all the necessary parameters to reconstruct the view.

But I continue to see lots of issue that could arise from this apprach. First you need a lot of code. Certainly if you refactor in a superclass you can avoid most of it, but this is always added complexity. For example, are you sure this is correct? viewId + "?product=" + product.getId(); I don't think, at least depends from the Faces Servlet mapping. And if you want something that work with every mapping? It is possible but now you need more code. I already pointed out some of the potential issues. The order of the execution of getter could be another. The most important is about back. What happen if a user display a product, then it hits the back button and try to display another product? The ID is different, but since the managed-bean is session scoped the property product is still there. The getter will see that product == null is false and won't reload the property. And request scoped bean is not good in this situation (becuse of save action). Again looking at your code I can see that reset method has been called too ealry causing a NPE. Ok, it is simple pseudo-code and we don't pretend to be correct, but I see a lot of potential issues caused by the chosen programming model. Almost most of them can be avoided using an action model.

viewId + "?product=" + product.getId();

It is always correct for my JSF applications.

The order of the execution of getter could be another.

This has not caused me problems. I'm careful about when I call the getters - usually from the view during Render Response.

The most important is about back. What happen if a user display a product, then it hits the back button
and try to display another product? The ID is different, but since the managed-bean is session scoped the property product is still there.

These are all good questions. My example is not complete. In reality I have run into this and what I do is check the ID parameter against the cached product's ID and if they are different I load the new product. I admit there are a lot of steps involved but it is manageable. It would be nice to have a framework that could automate this pattern for me, without bastardizing GET. :-)

Ok, it is simple pseudo-code and we don't pretend to be correct, but I see a lot of potential issues caused by the chosen programming model.
Almost most of them can be avoided using an action model.

True, the approach I have chosen has it's complexity, but fortunately it is only in the controller and not in the view. I can deal with that. (The view has its own inherent complexity.) The idea behind my approach is to get away from "submit form to see data" and simply load data on demand, intuitively for the user, via hyperlinking (hypertext is the engine of application state!), without requiring POST submissions, without changing state on the server, in a bookmarkable way. If you think RestFaces can do this, well, I'm interested. I would want to avoid YACF (yet another configuration file) so hopefully your no-XML approach can support a wide range of use cases. At the very least, hopefully everything your framework needs to declare can be done in faces-config.xml (I will have to review your documentation). I like the idea of GET event listeners for query purposes. Have you looked at JAX-RS (JSR 311)? It is the Java API for RESTful Web Services. Sun has a useful presentation on the subject. The reference implementation is called Jersey. Definitely worth a look. If you could model RestFaces after some of their concepts, that would be very cool. Jersey uses annotations to bind parts of the HTTP envelope to the resource (backing bean in JSF) in various ways, eg. field and method parameter injection (of URI elements, query string parameters, HTTP headers, and so on). I'm not against the idea of simple getters, only I haven't found a better, more reliable, more practical way of doing this yet. If you want some help with your framework, let me know. I think mining the HTTP envelope for more information and binding it to backing beans (via field and parameter injection) would be a great improvement over FacesContext to access HTTP info. You can reach me through the contact page on my site. Ian

The idea behind my approach is to get away from "submit form to see data" and simply load data on demand, intuitively for the user, via hyperlinking (hypertext is the engine of application state!), without requiring POST submissions, without changing state on the server, in a bookmarkable way.

If you think RestFaces can do this, well, I'm interested.

I think RestFaces can. Anyway also your code would probably work if you change the scope from session to conversation. I am not much into Seam, but, AFAIK, if you press button and click again the link who starts a new conversation, the product is null again and your code would work. The conversation scope is a so great thing!

Have you looked at JAX-RS (JSR 311)? It is the Java API for RESTful Web Services.

I have given a look at it now! thanks for the link because It seems very interesting. I see now that JSR 311 is under evaluation also from Expert Group of next JSF spec.
Anyway I think only a small part of it would be usefull for the usual html web applications. I'd like to introduce its approach in RestFaces anyway.

Jersey uses annotations to bind parts of the HTTP envelope to the resource (backing bean in JSF) in various ways, eg. field and method parameter injection (of URI elements, query string parameters, HTTP headers, and so on).

RestFaces 1.2 (not still a release) is going to support URI pattern, but from XML config file. It shouldn't be very difficult to implement this features throught annotations.

If you want some help with your framework, let me know. I think mining the HTTP envelope for more information and binding it to backing beans (via field and parameter injection) would be a great improvement over FacesContext to access HTTP info.

You can reach me through the contact page on my site.

Ian

Yes, I really need your help, expecially about these JSR 311 ideas. But I can't find any usefull email in http://www.jsftoolbox.com.

Yes, I really need your help, expecially about these JSR 311 ideas. But I can't find any usefull email in http://www.jsftoolbox.com.

Click on Contact Us (first paragraph) http://www.jsftoolbox.com/support/

A new JSF bookmarking tool is available, and has a slightly different approach from RestFaces. PrettyFaces is worth taking a look at!