Hi,
On Fri, Mar 20, 2015 at 7:45 PM, Kito Mann <kito.mann_at_virtua.com> wrote:
>
>
> OK, so that's not a technical reason. It's a philosophical one. There are
> limitations with server-side state saving, and using stateless views avoids
> those issues altogether. If all of my relevant state is in a view-scoped
> backing bean, I don't see a need for keeping the state of the component
> tree as well. If that's the case, then using a view-scoped bean with a
> stateless view makes sense.
>
I think so indeed.
What's in the view-scoped bean is a developer concern then. If it contains
real state (something that can not be restored) it's perhaps a bit weird,
but it can just as well consist of cache. In that case, if the session
expired and a new instance of the view-scoped bean is automatically created
at the next postback after that, code in said bean will just fetch the data
from its source.
But I do think the current limitation is because of a technical reason.
With stateless views the string “stateless” is used as the value for the
view state parameter (javax.faces.ViewState). In case of a non-stateless
view with server-side state saving, this would contain the view state ID. If
I'm not mistaken, this view state ID is used as key to find the matching
bean in the session (or more accurately, set up the view scope). I.e. the
key effectively segments the session.
If there's no ID for the view put in a hidden field for stateless views,
there's no key to use for lookup. A solution here might be to introduce a
new field, say "ViewId" (just like "WindowId"), which can be used to lookup
view-scoped beans.
Kind regards,
Arjan Tijms
>
> On 3/20/15, 12:47 PM, Kito Mann wrote:
>>
>> Hey Manfred,
>>
>> That makes sense to me. Perhaps you can answer my question, since you
>> added stateless views to Mojarra before they were added to the spec. Is
>> there a technical reason we can't associate view-scoped beans with a
>> stateless view?
>>
>> On Fri, Mar 20, 2015 at 1:37 PM, manfred riem <manfred.riem_at_oracle.com>
>> wrote:
>>
>>> Hi,
>>>
>>> Client side state saving does NOT save the view scoped beans in the view
>>> state.
>>>
>>> 4 important reasons why this is:
>>>
>>> 1. Alignment with the CDI version that stored them in the session in the
>>> first place.
>>> 2. Make @PreDestroy working properly.
>>> 3. Fixing inconsistency with respect to server side state saving.
>>> 4. Managed beans (in whatever scope) are NOT view state.
>>>
>>> Kind regards,
>>> Manfred Riem
>>>
>>>
>>>
>>> On 3/20/15, 12:22 PM, Kito Mann wrote:
>>>
>>>
>>> On Fri, Mar 20, 2015 at 1:15 PM, Bauke Scholtz <balusc_at_gmail.com> wrote:
>>>
>>>> (I just noticed I accidentally hit "Reply" instead of "Reply All", so
>>>> here's the jsr372 again)
>>>>
>>>> This is not stateless, contradicting the MVC ideology.
>>>>
>>>
>>> Ok, so it's not stateless. Call it whatever you want. I still don't
>>> see a technical reason that view-scoped beans can't be associated with
>>> "stateless" views.
>>>
>>>>
>>>> You could perhaps look at how JSF does client side state saving.
>>>>
>>>
>>> I know how client-side state saving works. That's not what I'm talking
>>> about.
>>>
>>> This way there's no state in server side and the views never expire.
>>>> This only requires everything in the view scoped bean to be Serializable.
>>>> You should also require an encryption key configured on the server side to
>>>> ensure security of the state in hidden input.
>>>>
>>>> This also needs to be instructed to endusers with caution, or they
>>>> would put "too many" data in view scoped beans (datatables!) which get
>>>> serialized forth and back to client which is inefficient, and then they
>>>> would complain about performance.
>>>>
>>>> Cheers, B
>>>>
>>>> On Fri, Mar 20, 2015 at 6:09 PM, Kito Mann <kito.mann_at_virtua.com>
>>>> wrote:
>>>>
>>>>> OK, let me clarify. I'm not talking about storing state for the view
>>>>> (I realize I said "view state" in the previous view). I'm just talking
>>>>> about having a way to associate a backing bean with a particular view and
>>>>> to keep that backing bean around as long as the view is currently being
>>>>> accessed. So, to answer your questions:
>>>>>
>>>>> * Where do you want to store that state on server side? Session?
>>>>> Application? Session, just as view-scoped beans are stored today.
>>>>>
>>>>> * How do you want to keep track of closed/expired views? This is
>>>>> less clear, since JSF wouldn't have a chance to clean up view-scoped
>>>>> objects when the view state is cleared. It would probably make sense to
>>>>> clear the view scope if another view is loaded within the same window.
>>>>>
>>>>> * What to do when user requests a view state which doesn't exist
>>>>> anymore because the session or application expired/restarted?
>>>>>
>>>>> If the session is expired, normal rules apply. If the app is
>>>>> restarted, the session is dead unless it was passivated, and if it was, the
>>>>> normal rules still apply.
>>>>>
>>>>> ___
>>>>>
>>>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>>>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>>>>> consulting
>>>>> http://www.JSFCentral.com | @jsfcentral
>>>>> +1 203-998-0403 <%2B1%20203-998-0403>
>>>>>
>>>>> * Listen to the Enterprise Java Newscast: *http://
>>>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>>>> <http://ww.enterprisejavanews.com>*
>>>>> * JSFCentral Interviews Podcast:
>>>>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>>>> * Sign up for the JSFCentral Newsletter:
>>>>> http://oi.vresp.com/?fid=ac048d0e17
>>>>>
>>>>> On Fri, Mar 20, 2015 at 12:42 PM, Bauke Scholtz <balusc_at_gmail.com>
>>>>> wrote:
>>>>>
>>>>>> To expand a bit on it: Where do you want to store that state on
>>>>>> server side? Session? Application? How do you want to keep track of
>>>>>> closed/expired views? What to do when user requests a view state which
>>>>>> doesn't exist anymore because the session or application expired/restarted?
>>>>>>
>>>>>> Cheers, B
>>>>>>
>>>>>> On Fri, Mar 20, 2015 at 5:36 PM, Bauke Scholtz <balusc_at_gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> View scope requires state on server side.
>>>>>>>
>>>>>>> Cheers, B
>>>>>>>
>>>>>>> On Fri, Mar 20, 2015 at 4:19 PM, Kito Mann <kito.mann_at_virtua.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Bauke, I understand the difference between MVC vs action/based
>>>>>>>> frameworks. I wrote an action-based framework right around the time Struts
>>>>>>>> came out, and I used Struts quite a bit before I got into JSF. I've also
>>>>>>>> worked with Spring MVC a little. I'm also on the MVC EG, which is where
>>>>>>>> others brought up the idea of a view scope for that framework.
>>>>>>>>
>>>>>>>> The point here is that if you define view state as being tied to
>>>>>>>> a particular session / view id / window id, then I don't see a reason you
>>>>>>>> can't use that as as a mapping for a view-scoped backing bean.
>>>>>>>>
>>>>>>>> ___
>>>>>>>>
>>>>>>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>>>>>>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>>>>>>>> consulting
>>>>>>>> http://www.JSFCentral.com | @jsfcentral
>>>>>>>> +1 203-998-0403 <%2B1%20203-998-0403>
>>>>>>>>
>>>>>>>> * Listen to the Enterprise Java Newscast: *http://
>>>>>>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>>>>>>> <http://ww.enterprisejavanews.com>*
>>>>>>>> * JSFCentral Interviews Podcast:
>>>>>>>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>>>>>>> * Sign up for the JSFCentral Newsletter:
>>>>>>>> http://oi.vresp.com/?fid=ac048d0e17
>>>>>>>>
>>>>>>>> On Fri, Mar 20, 2015 at 11:04 AM, Bauke Scholtz <balusc_at_gmail.com
>>>>>>>> > wrote:
>>>>>>>>
>>>>>>>>> MVC is request/action based not component based and therefore
>>>>>>>>> indeed inherently stateless in server side perspective. If MVC developer
>>>>>>>>> intends to have view state in both server and client side, it should be
>>>>>>>>> homegrown by manually carrying around some view state identifier via
>>>>>>>>> request parameter(s) to request scoped beans and maintaining it in server
>>>>>>>>> side session (or switch to component based MVC like JSF which has already a
>>>>>>>>> builtin solution for that, the view scope).
>>>>>>>>>
>>>>>>>>> Food for read and thought:
>>>>>>>>> - http://stackoverflow.com/a/4804476
>>>>>>>>> - http://stackoverflow.com/a/4424775
>>>>>>>>> - http://stackoverflow.com/a/7031941
>>>>>>>>>
>>>>>>>>> Cheers, B
>>>>>>>>>
>>>>>>>>> On 14:13, Fri, Mar 20, 2015 Kito Mann <kito.mann_at_virtua.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Ok, maybe I'm missing something here. Aren't we discussing having
>>>>>>>>>> view-scoped beans for the MVC spec? Aren't all views in MVC stateless?
>>>>>>>>>>
>>>>>>>>>> ___
>>>>>>>>>>
>>>>>>>>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>>>>>>>>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>>>>>>>>>> consulting
>>>>>>>>>> http://www.JSFCentral.com | @jsfcentral
>>>>>>>>>> +1 203-998-0403 <%2B1%20203-998-0403>
>>>>>>>>>>
>>>>>>>>>> * Listen to the Enterprise Java Newscast: *http://
>>>>>>>>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>>>>>>>>> <http://ww.enterprisejavanews.com>*
>>>>>>>>>> * JSFCentral Interviews Podcast:
>>>>>>>>>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>>>>>>>>> * Sign up for the JSFCentral Newsletter:
>>>>>>>>>> http://oi.vresp.com/?fid=ac048d0e17
>>>>>>>>>>
>>>>>>>>>> On Fri, Mar 20, 2015 at 9:09 AM, manfred riem <
>>>>>>>>>> manfred.riem_at_oracle.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> Indeed that is correct.
>>>>>>>>>>>
>>>>>>>>>>> Kind regards,
>>>>>>>>>>> Manfred
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 3/20/15, 8:05 AM, Bauke Scholtz wrote:
>>>>>>>>>>>
>>>>>>>>>>> Because there's no means of a view state.
>>>>>>>>>>>
>>>>>>>>>>> Cheers, B
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Mar 20, 2015 at 2:01 PM, Kito Mann <kito.mann_at_virtua.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> So, if that's the case, does anyone know why stateless views
>>>>>>>>>>>> can't reference view-scoped beans?
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, Mar 19, 2015 at 10:57 AM, arjan tijms <
>>>>>>>>>>>> arjan.tijms_at_gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Thu, Mar 19, 2015 at 3:18 PM, Kito Mann <
>>>>>>>>>>>>> kito.mann_at_virtua.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> As usual, the stateful nature of views is causing some issues
>>>>>>>>>>>>>> in an app I'm working on. Is there any particular reason that @ViewScoped
>>>>>>>>>>>>>> beans can't be used with stateless views? I think the only reason we have
>>>>>>>>>>>>>> that limitation is because of where they are stored, which could be
>>>>>>>>>>>>>> changed...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> If I'm not mistaken that location has already been changed,
>>>>>>>>>>>>> has it not?
>>>>>>>>>>>>>
>>>>>>>>>>>>> @ViewScoped beans used to be stored in the view state, which
>>>>>>>>>>>>> caused several timing issues. Since then it has been moved to the session.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Kind regards,
>>>>>>>>>>>>> Arjan Tijms
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ___
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Kito D. Mann | @kito99 | Author, JSF in Action
>>>>>>>>>>>>>> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training
>>>>>>>>>>>>>> and consulting
>>>>>>>>>>>>>> http://www.JSFCentral.com | @jsfcentral
>>>>>>>>>>>>>> +1 203-998-0403 <%2B1%20203-998-0403>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> * Listen to the Enterprise Java Newscast: *http://
>>>>>>>>>>>>>> <http://blogs.jsfcentral.com/JSFNewscast/>enterprisejavanews.com
>>>>>>>>>>>>>> <http://ww.enterprisejavanews.com>*
>>>>>>>>>>>>>> * JSFCentral Interviews Podcast:
>>>>>>>>>>>>>> http://www.jsfcentral.com/resources/jsfcentralpodcasts/
>>>>>>>>>>>>>> * Sign up for the JSFCentral Newsletter:
>>>>>>>>>>>>>> http://oi.vresp.com/?fid=ac048d0e17
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>