JSF 2.0 - Possibilities of bean scopes

I posted a couple of questions but haven't gotten any reply yet. Everything I state here concerns JSF 2.0.* mostly.

A typical bean contains information to be displayed on a page. Common business web-based application is a set of pages where each of them involves view-edit-save state which are represented by several xhtml pages. So we create a single bean to manage those states. But there are several problems I will describe shortly:

1) Each page is a different view thus forcing you to place bean into a session scope. It takes its toll in bloating the session storage.

2) Passing parameters between views. In order to edit a document one should know ID of the document or/and another set of objects. Placing them into a session is not a good decision (bloated session antipattern).

So far several attempts to rectify a situation have been tried.

a) t:saveState. It has been doing its job for many years. But now we are getting rid of it. b) Seam conversation. It has imposed so many problems concerning an exact moment the conversation dies. Time out is not an easy parameter to be set since we don't know how long a business user will, for example, be editing a document. Not a solution for us.

c) CODI(not tried) It seems to be a nice JSR 299 implementation and, potentilly can solve all out problems but it is so scarcely documented and, since being an extension, sticks to the WELD which is another framework and we just want to use all the power of JSF.

d) Spring web flow. Well, it is a very nice framework, documented abundantly, great IOC container, flow scope and all other nice things it provides can be a remedy. It solves multiply tab problem(it is my wording, so forgive me if it is unclear what I am getting at). Imagine we have an edit page and view scoped bean and we are filling the form. If users opens another page in a new tab, GET request is fired and the bean goes out of scope. Web flow can recognise such a problem and starts a new flow if a new tab has been opened.

(continuation on Web Flow)But it is monolithic and will force us to rewrite the whole project. Yes, I know it supports JSF and I have tested and fumbled with it for a little while to see whether it fits the bill or not. It doesn't because of its security. Unfortunately we don't have time nor resources to build a new project from scratch.

We have almost run out of solutions. JSF is a great framework, has been tested extensively and used in many projects. But the developers refuse to i开发者_如何学编程nclude CDI in it.

Can anyone recommend any solution to edit-view-save problem with a single bean? Any architectural advice will be of great help. Thank you so much in advance.

First of all: this is rather a discussion than a question, so there will never be a clear 'yes' or 'no'... There are always pros and cons beyond objective arguments (the developers dont like it) ;-)

Anyhow, let me start with the ascertainment that your situation is very common for all kind of web applications, and the problems you are describing are even more common for everyone who thinks about web application development from a architectural point of view.

Being confronted with an almost identical scenario over a year ago, here is our architecture:

Java EE 6 with JSF 2.0, CDI ( + EJB 3 & JPA, but this is beyond the scope of this answer).

• ViewScoped Beans, one per View (JSF ViewScope connected to CDI with Seam 3 Faces)
• ConversationScoped SFSB as facade per usecase for the business-logic, transaction / security boundary (facade being references by 1 - n view controllers)
• RequestScoped Services (stateless to be reusable for other clients (through different facades)

All this works like a charm, with almost no glue code between the layers.

1) Each page is a different view thus forcing you to place bean into a session scope. It takes its toll in bloating the session storage.

2) Passing parameters between views. In order to edit a document one should know ID of the document or/and another set of objects. Placing them into a session is not a good decision (bloated session antipattern).

I'm absolutely with you. That's why we use conversations.

b) Seam conversation. It has imposed so many problems concerning an exact moment the conversation dies. Time out is not an easy parameter to be set since we don't know how long a business user will, for example, be editing a document. Not a solution for us.

With 3 years experience of Seam 2 / 3 in production, I assure you that this is absolutely manageable. A conversation fits a usecase like a glove, and after a while you don't want to use anything else again. And certainly not the session ;-)

c) CODI(not tried) It seems to be a nice JSR 299 implementation and, potentilly can solve all out problems but it is so scarcely documented and, since being an extension, sticks to the WELD which is another framework and we just want to use all the power of JSF.

If you want to use CODI you dont need Weld, both are JSR 299 implementations. At the time of writing, Weld is far better documented and used more often. I don't even know if CODI is final?

d) Spring web flow. Well, it is a very nice framework, documented abundantly, great IOC container, flow scope and all other nice things it provides can be a remedy. It solves multiply tab problem(it is my wording, so forgive me if it is unclear what I am getting at). Imagine we have an edit page and view scoped bean and we are filling the form. If users opens another page in a new tab, GET request is fired and the bean goes out of scope. Web flow can recognise such a problem and starts a new flow if a new tab has been opened.

The multitab problem is solved by Seam / Weld / CODI as well. That's so ninetieths...

We have almost run out of solutions. JSF is a great framework, has been tested extensively and used in many projects. But the developers refuse to include CDI in it.

The problem with JSF is that your projects are not greenfield. You need to connect to a backend, and you will have problems doing this with pure JSF-scopes and technologies.

All I can tell you: I too had to convince my co-workers to use CDI. I did it with a working prototype in the described layout, and now, a year later everyone in the team is quite happy with our technology stack... :-)

To summarize this rather lengthy answer:

Java EE 6 is great technology stack for that kind of applications, and you should give it a try. The problems you are describing are not only solvable with Java EE 6, instead they were rather the problems the spec team had in mind when they designed the APIs.

Feel free to post further questions / doubts, if you like.

Just a general note:

OpenWebBeans, Weld and CanDI are JSR-299 implementations, thus the real containers providing the functionality of managing contextual instances, contexts, events, etc.

CODI is a portable JSR-299 Extension (like Seam3 is) which will run on any CDI container. You can use CODI on all the CDI-containers mentioned above.

CODI basically provides a few different things:

1.) a core module which contains useful stuff like @ProjectStageActivated (enabling/disabling beans based on the JSF ProjectStage), injectable Messages,

2.) JSF support modules with lots of additional scopes like @ViewAccessScoped, @WindowScoped (bean per window), @ConversationGroup, type safe @View navigation, CDI @PhaseListener, etc

3.) JPA @Transactional support. This will give you easy persistence without the need of using EJBs