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
>
>