Hi
AT> The argument boils down to why applications would choose between state on
AT> server or state on client in the first place.
AT>
AT> Both have their advantages and disadvantages; state on client effectively
AT> distributes the memory to the client saving server memory and usually
AT> doesn't expire as fast, but comes at the expensive of
AT> serialization/encryption and de-serialization/decryption costs and increased
AT> bandwidth requirements.
AT>
AT> State on server is pretty much the opposite, especially if references are
AT> used (javax.faces.SERIALIZE_SERVER_STATE set to false); no serialization and
AT> bandwidth costs, but expires fast and takes up server memory.
AT>
AT> The question is now whether these advantages and disadvantages really weigh
AT> exactly the same for each and every view in a given application, or that it
AT> may be different for at least some views?
AT>
AT> For instance, an application may have a public part and a logged-in part.
AT> For the public part sessions are often set to a very short timeout (e.g. a
AT> minute), while for the logged-in part it can be much longer (e.g. 30
AT> minutes). With such a short timeout for the public part, state on server is
AT> unfeasible, but storing it on the client can negatively impact the logged-in
AT> part. E.g. if those pages use a lot of AJAX requests sending state back and
AT> forth can easily cause the mentioned client state costs to become too much.
AT>
AT> Of course the user can separate the app into different web modules and set
AT> state saving accordingly for each module, but this is a rather heavyweight
AT> solution.
AT>
Ok, now I get it. So it could be situations, where the application by its own
purpose defines the state saving mode. I can assume that define it in f:view
has sense by flexibility. Sometime you only have this requirement for a
couple of views.
I personally like the url-pattern approach, because you can define both areas
and specified views, without change the page. Defining this in f:view has the
disadvantage of make the state definition more complex, because you need
to open the xhtml files to see how that's working.
Please note theoretically f:view can be used inside a template, so with one
definition you could apply the state saving to different views, without warning.
If you are using a resource library contract, a bad f:view can override that.
It doesn't look good for application where you want to force server side. It
looks better to define it on f:metadata, because f:metadata needs to be
defined on the top level.
AT> For sure, handling the ViewExpiredException has a strong relation with this
AT> use case. Indeed, we initially developed the restorable view handler in
AT> OmniFaces (see
AT>
http://showcase.omnifaces.org/taghandlers/enableRestorableView) as an
AT> alternative for setting state on client per view.
AT>
AT> But handling a ViewExpiredException by restoring the view again has its
AT> limitations. If there was in fact state its simply lost. If you know there
AT> will pretty much always be state, being able to save state on the client may
AT> still be the better option.
AT>
I can remember an option added in MyFaces that stores a timestamp with
the view and in that way a view stored in client can be expired.
Suppose this case: JSF 2.2, set the state to client and you have a page with
view scope beans. The session expired, the beans are dead but the state
is cliente, the view is restored but since the view relies on the view scope
beans the view crash unexpectedly. The reason? ViewExpiredException,
with client side state saving. But please note JSF "as is" doesn't detect this
case, but it is valid.
Note in JSF 2.1, if client side state saving is enabled, the view scope beans
are stored on the client with the state.
What's the point? for some applications, store view scope beans on the
client is a security risk (the data is encrypted and tampered of course, but
anyway something just not acceptable), but for some others it is not,
instead, you really want to store them on the client, because you don't want
to see the ViewExpiredException.
It start to have sense a view scope that is stored always on the client
(ClientViewScope?).
In conclusion:
1. Sometimes you want to avoid ViewExpiredException at all cost, the
application just should not see it ever.
2. Sometimes you want to have a session timeout and if a
ViewExpiredException happens, handle it as part of your application logic
(not as an unexpected exception).
AT> I'd also like to mention that the umbrella issue of "more flexible state
AT> saving" was largely2 intended as a point of discussion as well, to research
AT> how state saving in general can be made more flexible. As it stands, the
AT> topic of state comes up rather often in discussions about JSF and people do
AT> express the wish for things to become more powerful and more flexible
AT> (without explicitly mentioning -how- this should be done).
AT>
AT> Given this general and abstract wish, the ability to set where state is
AT> saved per view (or per URL pattern, of course) to me seemed the easiest and
AT> most well understood case with likely the least impact.
AT>
Thanks for mention your thoughts about this. It helps to keep in mind
what's important.
regards
Leonardo
> Kind regards,
> Arjan
>
>
>
>
>>
>>
>>
>>>
>>> MR>> And what do you mean add it to the faces-config.xml?
>>>
>>> For example in faces-config.xml we have this for contracts:
>>>
>>> <application>
>>> <resource-library-contracts>
>>> <contract-mapping>
>>> <url-pattern>*</url-pattern>
>>> <contracts>blue</contracts>
>>> </contract-mapping>
>>> </resource-library-contracts>
>>> </application>
>>>
>>
>>>
>>> It just look natural to me to do something similar for state saving. The
>>> advantage is you can change the faces-config.xml without change
>>> the entire application or recompile the code.
>>
>>
>> OK seems fair to me too. Arjan can you prototype the particulars for this?
>>
>> Regards,
>> Manfred
>>
>