Best JSF framework/library for "conversation state" - jsf

What do people think is the best JSF framework or library for a saving state longer than request scope (but w/o using session scope) that is backbutton/new window safe -- i.e. you have a "wizard"/multi-page form.
For example, MyFaces has the 'SaveState' tag that allows you to maintain state across pages by saving state in the view's component tree. Any comments on SaveState (pros/cons) or suggestions for any better framework or library for this capability?

The t:saveState works perfectly. It's only a bit 'low level' and not tied to a particular bean. There are two other libraries/frameworks which comes to mind which provides control over conversation scope at higher level (e.g. bean-specific tags/annotations):
Apache MyFaces Orchestra (uses tags)
JBoss Seam (uses annotations)
Update: JSF2.0 has added a new scope which achieves a conversation-like state, the #ViewScope. Very useful if you can reuse the same view for subsequent actions.

i think Spring Web Flow is a good solution. you can define your flow as XML and it can integrate with JSF, Struts, Spring MVC, ZK,...
http://www.springsource.org/webflow

Related

Advantages of using JSF Faces Flow instead of the normal navigation system

I'm exploring the JSF 2.2 Faces Flow feature but I'm still not sure what are the advantages of defining a flow using Faces Flow instead of using the normal navigation system (calling facelets in links or buttons)?
Only use it if you want to use a #FlowScoped bean on a given set of views. In other words, only use it if you want a managed bean which should live as long as you're navigating through the specified collection of views registered in the flow configuration file.
There are indeed very few real world use cases for this. They all boil down to a multi-step wizard of which each step is bookmarkable. Previously, before the introduction of the flow scope, one would use conditionally rendered includes for this, but they are in turn not individually bookmarkable, because the URL stays the same all the time.
See also:
What is new in JSF 2.2? - Faces Flow
Java EE 7 tutorial - Using Faces Flows
How to navigate in JSF? How to make URL reflect current page (and not previous one)
Faces flow and navigation are different.
Face flow like business flow in the frond end site, much like wizard.

How to disable ViewState?

I'm coming into Java world from MS and ASP.NET and looking for the similar to ASP.NET component-based HTML framework in Java. After reviewing tons of links in internet it looks like JSF2 (with facelets) is best match (is this true by the way? or there are other better choices?).
The problem I'm encountering during evaluation right now is correct usage of JSF's view state. My final usage scenario would be a clustered WEB server and i'm NOT going to have any session/server-stored objects and i'm NOT going to use network bandwidth for dummy view state (see another guy's somewhat related problem here JSF Tuning).
I took some JSF2 tutorial and after setting javax.faces.STATE_SAVING_METHOD = client got ViewState generated into HTML of 440 chars (omygod, page contains just 1 dummy text input and 1 submit button). In "POST on submit" I do need only text from text input (10 chars) and not that dummy view state (440 chars).
So the question is - Is it possible to disable view state in JSF2?
Relevant links:
Use-case in ASP.NET - "Disable View State for a Page":
http://www.ironspeed.com/articles/Disable%20View%20State%20for%20a%20Page/Article.aspx
Not helpful answer on stackoverflow:
How to reduce javax.faces.ViewState in JSF
Update: Relevant links (from comments below):
JSF 2.0 partial state saving does not seem to work
"Stateless JSF": http://industrieit.com/blog/2011/11/stateless-jsf-high-performance-zero-per-request-memory-overhead
JSF is a component based framework which is heavily stateful - so you need the state somewhere, either sent to the client over the wire and posted in again, or on the server side. So AFAIK the answer is No, you cannot disable the View state. But you can minimize it - however some state will always need storing. This link is relevant.
If you're looking for a Java web framework which is not so stateful - then maybe look at some Action based framework like Struts or Stripes, so you can work in Request scope and not need a component tree present (or rebuilt) on a postback. The Play framework has been gaining good press - which is specifically designed to target RESTful architectures. I do not have experience of this myself, but you may want to investigate it. Taken from the Play website:
Simple stateless MVC architecture
You’ve got a database on one side and a web browser on the other. Why
should you have a state in between?
Stateful and component based Java Web frameworks make it easy to
automatically save page state, but that brings a lot of other
problems: what happens if the user opens a second window? What if the
user hits the browser back button?
Since Mojarra 2.1.19 and Mojarra 2.2.0-m10 it's possible to disable the state saving on a per-view basis by setting the transient attribute of <f:view> to true.
<f:view transient="true">
...
<h:form>
...
</h:form>
...
</f:view>
See also:
JSF is going stateless
What is the usefulness of statelessness in JSF?

JSF 2 Custom Scope usage

I am going through all the scopes in JSF2.0. I am a little confused about when to use custom Scope. Any specific use cases it will be useful.
Initially I thought I can use it for scope spanning multiple pages like three page registration etc. But looks like we cannot use it there.
Better late than never: I wrote an article about the usage custom scopes in JSF2 : JSF 2 Custom Scopes without 3rd party libraries
Well, the general idea is to create your own Scope for what ever you like e.g. kind of "Conversation Scope". The problem is already adressed within JSR 299 (CDI) and imho this is where it belongs to.
My attempts to create a custom scope resulted in Exceptions thrown by the JSF implementation as soon as the context is destroyed. Since it seems that there are no working examples available, custom scopes should be considered as non-existent in JSF2.0, though announced as a key feature.
Anyway, if you are looking for custom scopes take a look at CDI (escpecially Weld and MyFaces CODI), MyFaces Orchestra (for Conversation Scopes in JSF), Seam (offers a nice solution) or create a Custom Scope using Spring.
HTH

JSF Adoption and Popularity

Just a general question, open for discussion...
I'm very much liking JSF so far, I'm new to it, but I prefer it to Struts. From a professionals standpoint, do you see a strong future for JSF ? Is it worth an investment as a young programmer to learn JSF 2.0 over Struts or another similar framework ? Should I stick to regular JSP ? Is Ajax really simpler through JQuery than JSF ?
I like new technologies and I like what I see so far from JSF but I want to be practical as well, and a lot Google searches turn up some bluntly critical comments about JSF 2.0.
Thoughts ?
Comparing JSF with Struts is like comparing apples with oranges. Struts is a request/action based MVC framework while JSF is a component based MVC framework. Struts is also aged. In the IT you're supposed to keep moving. Generally, a component based MVC framework is seen as a further evolution of a request/action based MVC framework.
JSF is currently already used very widely. It has indeed received a lot of critism before. You can read about most of them in the question What are the main disadvantages of JSF 2.0? The strength of JSF is mainly being a Java EE maintained standard and the availability of relatively a lot of 3rd party component libraries (PrimeFaces, RichFaces, IceFaces, OpenFaces, Tomahawk, etc). With JSF, it's very easy to develop CRUD applications and web forms with nice look'n'feel quickly.
However when it goes into the complex, JSF may cause some unforeseen surprises. Although the JSF specification and reference implementation (Mojarra) is pretty mature since the latest 1.2 builds, you may encounter some very specific behavioral problems which goes against your intuition. Some are just "by design" and can only be understood when you understand in detail how JSF works under the covers which in turn often boils down to the stateless nature of the HTTP protocol. JSF abstracts it in essence "too much" away that you don't see it anymore. Some are just bugs in the 3rd party component libraries used, but that's thus not strictly JSF-implementation-specific. Bug/issue handling is however pretty good in most of the major component libraries -if you report the bugs timely.
As to ajaxical stuff, JSF 2.0 indeed provides very little manual control over manually firing ajaxical requests and controlling the view tree in both server and client side. Simply because it's a component based MVC framework which keeps the tree state at the both sides. You've got to take the both sides into account when taking the ajaxical works in your own hands. If you really need more freedom in ajax/request based actions, then a component based MVC framework is simply the wrong choice. You should pick a request/action based MVC framework instead like Spring MVC, Struts or Stripes, along with a JS library like jQuery. You however have to write lot of HTML/CSS/JS boilerplate yourself instead.

Why is the WebBeans (JSR-299) Conversation Context tied to JSF?

I am reading through the Public Review Draft of the Web Beans specification (JSR-299) and I am wondering why it is so 'tightly coupled' to JSF?
Especially the Conversation Context seems only be specified for JSF.
I understand, that it is a goal of WebBeans to integrate JSF and EJB3. But would it not make sense to specify the concept of conversations on a more general level (maybe for Servlets in general and not for a specific web framework)?
Is there any technical reason for this? I think it can hardly be, because Seam (which is some Kind of WebBeans-Prototype) does also support Wicket and provides the concept of conversations.
I think it would be helpful to have a Conversation Scope on Servlet level (injecting of conversation-scoped beans into servlets). In my understanding, this is not the case with the ciurrent specification (see chapter 8.5.4). Or am I misinterpreting something here ...
Just found this today. The reason why the ConversationScope is JSF based is simply because JSF is the standard UI framework for Java EE!
Beside this, most of the JSR-299 containers can provide Conversations for other UI technologies like e.g. Wicket too.
Otoh you can easily create your own Scopes which are even portable.
LieGrue,
strub
I think it's soley down to Gavin King picking JSF as his view technology for Seam and him pushing through the JSR as spec lead.
Clearly conversations go wider - for instance, Spring custom scopes have a facility for providing conversations:
http://static.springframework.org/spring/docs/2.5.x/api/org/springframework/beans/factory/config/Scope.html

Resources