Hi Leonardo,
On 9/24/14, 1:32 PM, Leonardo Uribe wrote:
> 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.
OK that is fair. Arjan can you give him some arguments for supporting this?
>
> 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