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