Hi
I forgot to mention that one reason users switch from server to
client side state saving is avoid the ViewExpiredException. It
will happen anyway if the server is restarted and a new key
is generated, but sometimes lik in a cluster this key is
harcoded somewhere (web.xml).
The thing is there are some situations where you do not want
to use client side and force server side always and viceversa.
What we need to clarify is if this is a developer's concern and
if that so, add it to f:view has sense.
regards,
Leonardo Uribe
2014-09-24 13:32 GMT-05:00 Leonardo Uribe <leonardo.uribe_at_irian.at>:
> Hi Manfred
>
> LU>> Going back to the original topic, in my personal opinion "where the
> LU>> views are saved" is a concern on deployment, not something to be done
> LU>> by the application developer. It has sense to add it on faces-config.xml,
> LU>> but not on the view. What is a concern for the developer is handle
> LU>> with the ViewExpiredException in a more intuitive way.
>
> MR>> Just to clarify, are you opposed to the stateSavingMethod
> attribute on the view?
>
> 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.
>
> 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>
>
> An url-pattern is applied to the viewId to define which contracts should
> be applied to the view. MyFaces 2.2 implements a view pool and we
> use something similar:
>
> <faces-config-extension>
> <view-pool-mapping>
> <url-pattern>/*</url-pattern>
> <parameter>
> <name>org.apache.myfaces.VIEW_POOL_MAX_POOL_SIZE</name>
> <value>5</value>
> </parameter>
> </view-pool-mapping>
> </faces-config-extension>
>
> Again an url-pattern is applied to define which views are stored in the
> pool and the parameters.
>
> 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.
>
> regards,
>
> Leonardo Uribe
>
>> Regards,
>> Manfred
>>
>>
>> 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
>>
>>