You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by "Howard W. Smith, Jr." <sm...@gmail.com> on 2013/02/22 13:52:12 UTC

Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Mark Struberg, and to whom this may concern,

Please see my questions[1] and respond here and/or there in PrimeFaces
community forum.

I'm no longer a Mojarra user, but somewhat of a birdie sent word in my
email inbox this morning about Mojarra 2.1.19 having stateless JSF. So, I
wanted to see what MyFaces developers/community has to say on the topic.

Thanks,
Howard

[1] http://forum.primefaces.org/viewtopic.php?f=3&t=19101&p=91071#p91071

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by nabbling1138 <ne...@gmail.com>.
Howard W. Smith, Jr. wrote
>> ViewExpiredExceptions are 'no' longer a concern of mine since I am using
>> OmniFaces restoreView component.
> 
> Nice! I hadn't seen that. I will be checking that out.
> 
>> Also, for my home-grown/custom security-n-session-management
>> implementation, my login page access @SessionScoped userBean.login, but
>> since I've been hearing others advise to use @RequestScoped more than
>> @SessionScoped (as much as possible), I am considering changing my
>> implementation, so the login page will access @RequestScoped user bean
>> instead of @SessionScoped. I am quite sure that that will allow my login
>> page to sufficiently/theoretically avoid View Expired exception. I plan
>> to
>> try this...when I feel like it, or have bandwidth to do so. :)
> 
> Nope :( View state is still maintained even when only referencing
> RequestScoped beans. That is why the transient=true is so important. It
> will be the only standard built in way to avoid view state exceptions that
> I know of.





--
View this message in context: http://myfaces.10567.n7.nabble.com/Add-Stateless-JSF-to-MyFaces-Core-Is-it-really-necessary-tp114248p115116.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by Mike Kienenberger <mk...@gmail.com>.
On Wed, Jun 19, 2013 at 7:00 PM, Leonardo Uribe <lu...@gmail.com> wrote:
> It is good to know how a user expect to use this feature, so I'll keep in
> mind it the suggestions.

While I didn't previously have any need for stateless JSF, I might
need it in the future.

I've been asked to consider converting a struts/velocity web app I
wrote many years ago to JSF.  Conversion of velocity struts to
facelets is straight-forward.  However, struts is stateless, and
attempting to convert a struts application to stateful JSF would be
painful, as every struts request/response is independent of the next
one.   I'm kind of hoping that stateless JSF might work out better.

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi

Anyway, "transient" attribute was added in JSF 2.2, but there are not
strong enough reasons to add it to myfaces 2.1.x, which is the main
question of this thread.

Just for the record, there is a small difference when f:view
transient="true" is used. When there is a validation error, since there is
no view state, the previous values of the fields are not saved on the
component tree, but remember those values are sent as request parameters.
It doesn't suppose a problem, but in some cases it is relevant to keep it
in mind. Also, without view state token there is no built-in csrf
protection, but that could not suppose a problem too.

It is good to know how a user expect to use this feature, so I'll keep in
mind it the suggestions.

regards,

Leonardo
On Jun 19, 2013 5:48 PM, "Howard W. Smith, Jr." <sm...@gmail.com>
wrote:

> On Wed, Jun 19, 2013 at 12:15 PM, nabbling1138 <newton.whitman@gmail.com
> >wrote:
>
> >
> > It has everything to do with avoiding your users experiencing a
> ViewExpired
> > state exception on a trivial form such as a login.
> >
>
> ViewExpiredExceptions are 'no' longer a concern of mine since I am using
> OmniFaces restoreView component.
>
> Also, for my home-grown/custom security-n-session-management
> implementation, my login page access @SessionScoped userBean.login, but
> since I've been hearing others advise to use @RequestScoped more than
> @SessionScoped (as much as possible), I am considering changing my
> implementation, so the login page will access @RequestScoped user bean
> instead of @SessionScoped. I am quite sure that that will allow my login
> page to sufficiently/theoretically avoid View Expired exception. I plan to
> try this...when I feel like it, or have bandwidth to do so. :)
>
>
> > It is non-intuitive for users to get errors (however you have handled
> them)
> > on simple forms when they went to lunch and came back.
> >
>
> Agreed. Thank God for OmniFaces restoreView component!
>
>
> >
> > Example: Imagine going to your favorite shopping web site. You get
> > interrupted and come back in 30 min - you go to run a search and you get
> > redirected to a friendly but annoying web page or maybe they force you
> back
> > to a page but you loose everything you typed. Awful customer experience!
> >
>
> Good point/example. I felt the same way while developing my current
> security/session-management implementation (over time). My app is
> definitely no 'shopping web site' and endusers of my app are very
> understanding of a 15-minute-session-timeout limit for security purposes,
> and I would 'only' assume shopping web sites would require/utilize
> @RequestScoped beans anyway. Take for instance Google or MSN.com search
> engines... Google loves 'history' (and so do I), @RequestScoped bean
> accepts the input of the enduser, and can update 'search history',
> accordingly when user 'come back in 30 min' to his search page and press
> Enter...to begin the search. :)
>
> Surely, not rocket science.
>
>
> >
> >
> > --
> > View this message in context:
> >
> http://myfaces.10567.n7.nabble.com/Add-Stateless-JSF-to-MyFaces-Core-Is-it-really-necessary-tp114248p115108.html
> > Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >
>

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Wed, Jun 19, 2013 at 12:15 PM, nabbling1138 <ne...@gmail.com>wrote:

>
> It has everything to do with avoiding your users experiencing a ViewExpired
> state exception on a trivial form such as a login.
>

ViewExpiredExceptions are 'no' longer a concern of mine since I am using
OmniFaces restoreView component.

Also, for my home-grown/custom security-n-session-management
implementation, my login page access @SessionScoped userBean.login, but
since I've been hearing others advise to use @RequestScoped more than
@SessionScoped (as much as possible), I am considering changing my
implementation, so the login page will access @RequestScoped user bean
instead of @SessionScoped. I am quite sure that that will allow my login
page to sufficiently/theoretically avoid View Expired exception. I plan to
try this...when I feel like it, or have bandwidth to do so. :)


> It is non-intuitive for users to get errors (however you have handled them)
> on simple forms when they went to lunch and came back.
>

Agreed. Thank God for OmniFaces restoreView component!


>
> Example: Imagine going to your favorite shopping web site. You get
> interrupted and come back in 30 min - you go to run a search and you get
> redirected to a friendly but annoying web page or maybe they force you back
> to a page but you loose everything you typed. Awful customer experience!
>

Good point/example. I felt the same way while developing my current
security/session-management implementation (over time). My app is
definitely no 'shopping web site' and endusers of my app are very
understanding of a 15-minute-session-timeout limit for security purposes,
and I would 'only' assume shopping web sites would require/utilize
@RequestScoped beans anyway. Take for instance Google or MSN.com search
engines... Google loves 'history' (and so do I), @RequestScoped bean
accepts the input of the enduser, and can update 'search history',
accordingly when user 'come back in 30 min' to his search page and press
Enter...to begin the search. :)

Surely, not rocket science.


>
>
> --
> View this message in context:
> http://myfaces.10567.n7.nabble.com/Add-Stateless-JSF-to-MyFaces-Core-Is-it-really-necessary-tp114248p115108.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
>

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by nabbling1138 <ne...@gmail.com>.
I think you are missing the point. This has nothing to do with performance.
It has everything to do with avoiding your users experiencing a ViewExpired
state exception on a trivial form such as a login. 

It is non-intuitive for users to get errors (however you have handled them)
on simple forms when they went to lunch and came back. 

Example: Imagine going to your favorite shopping web site. You get
interrupted and come back in 30 min - you go to run a search and you get
redirected to a friendly but annoying web page or maybe they force you back
to a page but you loose everything you typed. Awful customer experience!



--
View this message in context: http://myfaces.10567.n7.nabble.com/Add-Stateless-JSF-to-MyFaces-Core-Is-it-really-necessary-tp114248p115108.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by Leonardo Uribe <lu...@gmail.com>.
Hi

To be clear use UIViewRoot#setTransient(true) just save time when
the state is calculated, because it just skip that calculation. But
in MyFaces, calculate the state is quite fast, so at the end the saved
time is less than 1 or 2%. Why? because what really has an impact
over the time spent processing a request is the rendering step and
compared to that time traverse the component tree is fast. PSS
algorithm has improved this situation a lot too, because usually most
of  the view does not have associated "delta" state, so the
encryption overhead becomes small.

In few words, don't worry about call UIViewRoot#setTransient(true),
better let the code as is.

regards,

Leonardo Uribe

2013/2/22 l.penet@senat.fr <l....@senat.fr>:
> On 22/02/2013 14:19, Howard W. Smith, Jr. wrote:
>>
>> Fair enough. Definitely not a concern of mine; seems not to be a real
>> concern to MyFaces Dev/users as well. :)
>
>
> Dear all,
>
> maybe a stupid question...
>
> So, a <f:view transient="true"> can be used to design a nice login form
> leveraging JSF power ?
>
> Best regards,
>
> Ludovic
> |
> | AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
> |
>

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by "l.penet@senat.fr" <l....@senat.fr>.
On 22/02/2013 14:19, Howard W. Smith, Jr. wrote:
> Fair enough. Definitely not a concern of mine; seems not to be a real
> concern to MyFaces Dev/users as well. :)

Dear all,

maybe a stupid question...

So, a <f:view transient="true"> can be used to design a nice login form 
leveraging JSF power ?

Best regards,

Ludovic
|
| AVANT D'IMPRIMER, PENSEZ A L'ENVIRONNEMENT.
|


Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Fair enough. Definitely not a concern of mine; seems not to be a real
concern to MyFaces Dev/users as well. :)


On Fri, Feb 22, 2013 at 8:15 AM, Thomas Andraschko <
andraschko.thomas@gmail.com> wrote:

> AFAIK UIViewRoot#setTransient(true) is defined in the specs.
> Maybe they implemented more features dependent on this flag, don't know.
> Someone should check there code :)
>
> 2013/2/22 Howard W. Smith, Jr. <sm...@gmail.com>
>
> > On Fri, Feb 22, 2013 at 7:55 AM, Thomas Andraschko <
> > andraschko.thomas@gmail.com> wrote:
> >
> > > This isn't exactly stateless, the viewRoot needs still to be created
> > every
> > > request. The state just won't be saved anymore.
> > >
> >
> > So, is this really a performance enhancement for Mojarra's important
> > performance issue/JIRAs? Is it (the performance) similar to a non-AJAX
> > response and update to the (xhtml) page...or similar to a Full Page
> Refresh
> > (FPR) ?
> >
> >
> > > This can be done via UIViewRoot#setTransient(true) with MyFaces, too.
> > >
> >
> > Interesting. Of course, MyFaces already has this built-in and/or
> addressed.
> > :)
> >
>

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by Thomas Andraschko <an...@gmail.com>.
AFAIK UIViewRoot#setTransient(true) is defined in the specs.
Maybe they implemented more features dependent on this flag, don't know.
Someone should check there code :)

2013/2/22 Howard W. Smith, Jr. <sm...@gmail.com>

> On Fri, Feb 22, 2013 at 7:55 AM, Thomas Andraschko <
> andraschko.thomas@gmail.com> wrote:
>
> > This isn't exactly stateless, the viewRoot needs still to be created
> every
> > request. The state just won't be saved anymore.
> >
>
> So, is this really a performance enhancement for Mojarra's important
> performance issue/JIRAs? Is it (the performance) similar to a non-AJAX
> response and update to the (xhtml) page...or similar to a Full Page Refresh
> (FPR) ?
>
>
> > This can be done via UIViewRoot#setTransient(true) with MyFaces, too.
> >
>
> Interesting. Of course, MyFaces already has this built-in and/or addressed.
> :)
>

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
On Fri, Feb 22, 2013 at 7:55 AM, Thomas Andraschko <
andraschko.thomas@gmail.com> wrote:

> This isn't exactly stateless, the viewRoot needs still to be created every
> request. The state just won't be saved anymore.
>

So, is this really a performance enhancement for Mojarra's important
performance issue/JIRAs? Is it (the performance) similar to a non-AJAX
response and update to the (xhtml) page...or similar to a Full Page Refresh
(FPR) ?


> This can be done via UIViewRoot#setTransient(true) with MyFaces, too.
>

Interesting. Of course, MyFaces already has this built-in and/or addressed.
:)

Re: Add 'Stateless JSF' to MyFaces Core? Is it really necessary?

Posted by Thomas Andraschko <an...@gmail.com>.
This isn't exactly stateless, the viewRoot needs still to be created every
request. The state just won't be saved anymore.
This can be done via UIViewRoot#setTransient(true) with MyFaces, too.

2013/2/22 Howard W. Smith, Jr. <sm...@gmail.com>

> Mark Struberg, and to whom this may concern,
>
> Please see my questions[1] and respond here and/or there in PrimeFaces
> community forum.
>
> I'm no longer a Mojarra user, but somewhat of a birdie sent word in my
> email inbox this morning about Mojarra 2.1.19 having stateless JSF. So, I
> wanted to see what MyFaces developers/community has to say on the topic.
>
> Thanks,
> Howard
>
> [1] http://forum.primefaces.org/viewtopic.php?f=3&t=19101&p=91071#p91071
>