Hi,
On Wed, Sep 24, 2014 at 8:48 PM, manfred riem <manfred.riem_at_oracle.com>
wrote:
> Not really, I just don't see a strong justification. Why the user would
>> force a
>> view to be saved on the client or on the server? security? performance?
>> I would like to have a list of arguments about this. And I see the problem
>> of handle ViewExpiredException as a more important concern.
>>
>
> OK that is fair. Arjan can you give him some arguments for supporting this?
The argument boils down to why applications would choose between state on
server or state on client in the first place.
Both have their advantages and disadvantages; state on client effectively
distributes the memory to the client saving server memory and usually
doesn't expire as fast, but comes at the expensive of
serialization/encryption and de-serialization/decryption costs and
increased bandwidth requirements.
State on server is pretty much the opposite, especially if references are
used (javax.faces.SERIALIZE_SERVER_STATE set to false); no serialization
and bandwidth costs, but expires fast and takes up server memory.
The question is now whether these advantages and disadvantages really weigh
exactly the same for each and every view in a given application, or that it
may be different for at least some views?
For instance, an application may have a public part and a logged-in part.
For the public part sessions are often set to a very short timeout (e.g. a
minute), while for the logged-in part it can be much longer (e.g. 30
minutes). With such a short timeout for the public part, state on server is
unfeasible, but storing it on the client can negatively impact the
logged-in part. E.g. if those pages use a lot of AJAX requests sending
state back and forth can easily cause the mentioned client state costs to
become too much.
Of course the user can separate the app into different web modules and set
state saving accordingly for each module, but this is a rather heavyweight
solution.
For sure, handling the ViewExpiredException has a strong relation with this
use case. Indeed, we initially developed the restorable view handler in
OmniFaces (see
http://showcase.omnifaces.org/taghandlers/enableRestorableView) as an
alternative for setting state on client per view.
But handling a ViewExpiredException by restoring the view again has its
limitations. If there was in fact state its simply lost. If you know there
will pretty much always be state, being able to save state on the client
may still be the better option.
I'd also like to mention that the umbrella issue of "more flexible state
saving" was largely intended as a point of discussion as well, to research
how state saving in general can be made more flexible. As it stands, the
topic of state comes up rather often in discussions about JSF and people do
express the wish for things to become more powerful and more flexible
(without explicitly mentioning -how- this should be done).
Given this general and abstract wish, the ability to set where state is
saved per view (or per URL pattern, of course) to me seemed the easiest and
most well understood case with likely the least impact.
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
>
>