Hi
Resending email to check it is delivered to users list.
AT>> ... all about where state is saved, not how state is saved ...
What I understand is in this point Arjan talks about define the state saving
on the view (through f:view) or using a url pattern (like resource library
contracts) or globally.
In the past I remember a similar discussion here:
https://issues.apache.org/jira/browse/MYFACES-3779
Mixed mode(Server+client) for state saving
The idea was use a mode that switch to client when some specific threshold
in the state size is achieved.
But the conclusion in that time was that the real problem is that JSF does
not
have a way to handle ViewExpiredException in a more "gracefully" way.
What I mean is not about the work in JSF 2.0 over ExceptionHandler:
https://weblogs.java.net/blog/edburns/archive/2009/09/03/dealing-gracefully-viewexpiredexception-jsf2
The problem is JSF does not handle ViewExpiredException gracefully
"by default".
For example. I enter to a specified flow, and the ViewExpiredException
happens by some reason, there is no way to say the system how to
recover from that error unless you write a custom ExceptionHandler
and do some calculations. It would be nice if we could find a declarative
approach to that and maybe fix this on Faces Flow.
Suppose a login form. The form has a view state. The session expired
I enter my username/password and then I submit. The deadly
ViewExpiredException happens. What is the default in this case?
add some message to the page and redisplay the form. But JSF doesn't
have a way to define such navigation in a declarative way. Note there
is two parts: an action (add the message) and a navigation (render the
view as if was the first time).
Ideas? why don't see a ViewExpiredException as a "view event", or
isn't this a "view action" that is triggered by a event?.
Going back to the original topic, in my personal opinion "where the
views are saved" is a concern on deployment, not something to be done
by the application developer. It has sense to add it on faces-config.xml,
but not on the view. What is a concern for the developer is handle
with the ViewExpiredException in a more intuitive way.
regards,
Leonardo Uribe
2014-09-24 11:46 GMT-05:00 Arjan Tijms <arjan.tijms_at_zeef.com>:
> Hi,
>
> On Wed, Sep 24, 2014 at 6:22 PM, manfred riem <manfred.riem_at_oracle.com>
> wrote:
> > Can you go into specific with regards to the attribute you would like to
> > see?
>
> Approximately something like:
>
> name:
> stateSavingMethod
>
> allowed values:
> server/client/[null]
>
> Semantics of the values "server" and "client" would be exactly like
> the context param "javax.faces.STATE_SAVING_METHOD", but just per view
> instead of for the entire application. [null] (not defining the
> attribute, or perhaps find a distinct value instead) would use
> whatever method is set globally.
>
> For example:
>
> mypage.xhtml
>
> <f:view stateSavingMethod="client" >
>
> ...
>
> <h:form>
> ...
> </h:form>
>
>
> </f:view>
>
> web.xml
>
> <context-param>
> <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
> <param-value>server</param-value>
> </context-param>
>
> Requesting /mypage.xhtml would cause the state for that view to be
> stored as the value of the hidden input field, despite the "server"
> setting for state saving in web.xml.
>
> Kind regards,
> Arjan
>
>
>
> >
> > Thanks!
> > Manfred
> >
> >
> > On 9/24/14, 10:48 AM, Arjan Tijms wrote:
> >>
> >> Hi there,
> >>
> >> A while ago I created umbrella issue
> >> https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1056 that
> >> asked for more flexible state saving in JSF.
> >>
> >> The issue being an umbrella issue actually asks for a couple of more
> >> specific things, but all about where state is saved, not how state is
> >> saved.
> >>
> >> Perhaps the most important part of the issue is the ability to set per
> >> view whether state is saved on the server or the client. Currently
> >> this can only be set globally for the entire application.
> >>
> >> I looked in the RI code a while ago and did some experiments with a
> >> custom build and the per view setting seemed doable. An attribute on
> >> f:view would be the most straightforward place to set this I guess.
> >>
> >> I wonder what your thoughts about this are.
> >>
> >> Kind regards,
> >> Arjan Tijms
>