[jsr-314-open] ViewScoped severe bug or expected behavior?

Kito Mann kito.mann at virtua.com
Thu Jan 20 11:58:13 EST 2011


Yeah, but it's a confusing "feature". So I think for 2.2 at least we should
introduce a more logical way to handle this, even if you have to turn it on
in web.xml.
---
Kito D. Mann | twitter: kito99 | Author, JSF in Action
Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter:
jsfcentral
+1 203-404-4848 x3

See you at JAX and JSF Summit 2010 June 20-23rd in San Jose:
http://jaxconf.com/



On Wed, Jan 19, 2011 at 10:29 AM, Werner Punz <werner.punz at gmail.com> wrote:

> Ok thanks for clearing this up. I guess I was too close to codi in my
> thinking here
> which keeps the state and does not care about the outcome redirects etc...
> It is not a bug then but a feature :-)
>
>
>
> Werner
>
>
>
> On Wed, Jan 19, 2011 at 9:30 AM, Martin Marinschek <mmarinschek at apache.org
> > wrote:
>
>> Well, whatever you do (and Leonardo is right here) it should behave
>> the same for the view state and the associated map (cause bindings
>> might reside in it).
>>
>> And: the behaviour is like this for a long time already. We would be
>> breaking existing apps if we change this (some people rely on this
>> different meaning, even though I myself never did - I found this to
>> subtle to rely on it ;)
>>
>> best regards,
>>
>> Martin
>>
>> On 1/14/11, Werner Punz <werner.punz at gmail.com> wrote:
>> > I dont think a reset should be done over a navigation case, a reset is
>> > clearly triggered by an api function.
>> > A ViewScope from my point of view should retain its state as long as it
>> is
>> > in the same viewId no matter
>> > how the navigation case triggers, it should only clear itself up in this
>> > stage if you issue a manual clearing command one way or the other.
>> >
>> > Werner
>> >
>> > On Fri, Jan 14, 2011 at 5:52 AM, asmirnov <asmirnov at exadel.com> wrote:
>> >
>> >> Different developers expect the diffirent behavior :-).
>> >> For me, that's helpful sometime as the way to reset page scope
>> variables.
>> >> On Jan 12, 2011, at 1:22 PM, Ted Goddard wrote:
>> >>
>> >> >
>> >> > I agree, losing the ViewMap upon navigation back to the same view
>> >> > doesn't
>> >> make
>> >> > sense.  Earlier discussion was divided (see messages with the
>> following
>> >> subject line):
>> >> >
>> >> > [jsr-314-eg] navigation to same viewId
>> >> >
>> >> > So we've added a feature into ICEfaces whereby @ViewRetained beans
>> are
>> >> > propagated across the ViewMap when such navigation occurs.
>> >> >
>> >> > Ted.
>> >> >
>> >> > On 2011-01-12, at 11:01 AM, Kito Mann wrote:
>> >> >
>> >> >> Werner, did you ever get a response about this?
>> >> >> ---
>> >> >> Kito D. Mann | twitter: kito99 | Author, JSF in Action
>> >> >> Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and
>> >> consulting
>> >> >> http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info |
>> >> twitter: jsfcentral
>> >> >> +1 203-404-4848 x3
>> >> >>
>> >> >> See you at JAX and JSF Summit 2010 June 20-23rd in San Jose:
>> >> http://jaxconf.com/
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Mon, Dec 20, 2010 at 6:23 AM, Werner Punz <werner.punz at gmail.com
>> >
>> >> wrote:
>> >> >> Hi I ran into following issue while doing some testing on MyFaces
>> and
>> >> after testing it on Mojarra I noticed that Mojarra behaves the same. So
>> I
>> >> am
>> >> not sure if this is a bug or expected behavior. Hence I am posting it
>> >> here.
>> >> >>
>> >> >> Following usecase.
>> >> >> a Page with a managed bean as page controller which is ViewScoped.
>> >> >>
>> >> >> Now the page keeps some data which is serialized per definition on
>> the
>> >> scope.
>> >> >> An action is triggered from the page which then issues an implicit
>> >> navigation case onto itself.
>> >> >>
>> >> >> Now what happens on both implementations is, that the ViewScoped
>> bean
>> >> >> is
>> >> dropped and the data is lost.
>> >> >>
>> >> >> This is easily reproducable with the case in the attachments.
>> >> >> As you can see the value is initially set to another value by the
>> >> postConstruct and then once the action is triggered it is reset to the
>> >> initial value, although it should
>> >> >> have been restored to the last value which was present before
>> issuing
>> >> the action onto itself.
>> >> >>
>> >> >> I could reproduce this behavior on MyFaces 2.0.3 and on Mojarra. Any
>> >> ideas if this is a bug or expected behavior? Because from a logical
>> point
>> >> of
>> >> view
>> >> >> a nav case should not retire the view scope if it hits the same page
>> >> again no matter if a redirect is in between if it is implicit or
>> explicit
>> >> or
>> >> if it is just
>> >> >> a null restore case.
>> >> >>
>> >> >>
>> >> >> Werner
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >> >
>> >> >
>> >>
>> >>
>> >
>>
>>
>> --
>>
>> http://www.irian.at
>>
>> Your JSF powerhouse -
>> JSF Consulting, Development and
>> Courses in English and German
>>
>> Professional Support for Apache MyFaces
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20110120/1dd0fa23/attachment-0002.html 


More information about the jsr-314-open-mirror mailing list