Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JSF2.2, RequestScope and component persistence  RSS feed

 
Nicola Cisternino
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all.
As reported in my stackoverflow post (http://stackoverflow.com/questions/24081208/jsf2-2-requestscope-and-component-persistence), my actual scenario is a simple JSF project that uses Mojarra 2.2.5.
I'm trying to get programmatically a component instance (via "findComponent" method or binding ...) and set some attributes (click on "ChangeColor" button).
After that, using any other action (for example clicking on "Send" button), the previous changes are ignored !!
It seems that changeColor method don't update the ViewState !
The sample code is the following:

And the relative RequestScope bean:

Some important considerations:
1) I must use RequestScope for compatibility reasons.
2) Setting javax.faces.PARTIAL_STATE_SAVING to "false" all works fine (!).
3) Trying to use MyFaces 2.2.3 libraries all works fine (!).
4) Trying to use Mojarra 1.2 libraries all works fine (!).

What do you think about ?
Thanks.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There are 2 or 3 Fundamental Rules of JSF, and one of them is this: Request Scope is almost 100% useless in JSF.

JSF doesn't work like other web frameworks. It uses a postback mechanism of repeated requests, and since any object in request scope gets destroyed at the end of the request, you will lose state, and that includes critical View-control information.

I don't actually count it as a rule, but it's not good practice to use locator logic for JSF. JSF is designed around Inversion of Control (IoC), which is the exact opposite - beans don't go looking for stuff, JSF injects stuff into the beans automatically.

The proper way to do what you want looks more like this:


Paired with:


Remember I said that there are 2 or 3 Basic Rules of JSF? Well, Rule #1 is as follows:


The more JSF-specific your JSF code is, the more likely it is that you are doing it wrong.


If you'll note, everything I did was done using POJO constructs. Not a javax.faces object or method to be found.
 
Nicola Cisternino
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Tim, and thank You for replay.
Some questions for you:
1) OK, "... object in request scope gets destroyed at the end of the request ... " but viewroot restore is the first of JSF cycle phases, or not ?
2) Why some attribute are restored ("value" attribute, for example ...) and some others ("style" attribute, in my test case) none ?
3) What's the complete list of "restorable" attribute ?
4) Why JSF1.2 restore all view attributes ?
5) Why MyFaces implementation restore all view attributes ?
6) What's "Fundamental Rules of JSF" complete list ? Who created it ?
I understand your "Basic Rule" philosophy, but I've an application migrated from JSF 1.2 (with hundreds of installations) and, at this time, I don't need ViewScope ... instead, I expect that at least view restore works fine!
Thanks again.
 
Tim Holloway
Bartender
Posts: 18531
61
Android Eclipse IDE Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The first phase of the JSF lifecycle is, in fact "View Restore", but when you are running in Request Scope, the View being restored was created from the incoming Request, and NOT from existing context. That's because the previous context was destroyed after the previous request was processed.

When you are first rendering a View, the property values are rendered via JSF's built-in Controllers, which transfer property values from the Model (backing bean) to the View. In the case of a Request-scope bean, the bean is reconstructed from scratch with every view request, and therefore state does not carry over. You'll always be rendering the initial values of the backing bean's properties. That is, every request is effectively a "first request".

There is no list of "restorable attributes". JSF doesn't work that way and it never did. JSF works with Models and Views, which it binds using Controllers that it provides itself.

MyFaces adheres to the same architectural rules as core JSF and as any other well-behaved JSF extension. There's no difference in how things are done.

There never was a formal "Fundamental Rules" list. You're familiar with Frequently-Asked Questions? Well, those are my "Frequently-Supplied Answers". You'll see me quoting them over and over in the archives of this forum, because they embody essential things about JSF that everyone should know.

And finally, although a lot of things changed from JSF version 1 to JSF version 2, the essential architecture did not. The same "Fundamental Rules" apply to both. However, breaking the rule about not coding JSF-dependent code where you can avoid it has a double penalty. Not only is the code more complex than it needs to be, it's more likely to break when a new version of JSF comes out. Which seems to be what happened here.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!