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(a)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(a)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(a)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(a)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