Lazy initialization during backtracking

[GoogleCodeExporter]

If backtracked state is initialized lazily during the rendering phase, state 
changes are not snapshot 
and therefore lost.

Original issue reported on code.google.com by renggli on 7 Feb 2009 at 4:04

[GoogleCodeExporter]

I know why this is. I thought it was intentional. I need to think about it...

don't anybody waste your time tracking it down in the meantime.

Original comment by jfitz...@gmail.com on 7 Feb 2009 at 4:31

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Need to move this one to 2.9b1, because 2.9a2 is a thing of the past.

Original comment by renggli on 11 Aug 2009 at 4:32

• Added labels: Milestone-2.9b1
• Removed labels: Milestone-2.9a2

[GoogleCodeExporter]

Original comment by jfitz...@gmail.com on 4 Sep 2009 at 8:33

• Added labels: Milestone-3.0b1
• Removed labels: ****

[GoogleCodeExporter]

Original comment by jfitz...@gmail.com on 4 Sep 2009 at 8:38

• Added labels: ****
• Removed labels: Milestone-2.9b1

[GoogleCodeExporter]

Ok, Lukas, Philippe, Dale, and I discussed this.

State is saved in the RenderPhaseContinuation at the beginning of each render 
loop (including the first loop 
of the application). This state is then passed to the ActionPhaseContinuation 
and is only updated after an AJAX 
request. When we begin the next loop iteration, we capture again.

If, at the beginning of the first render phase, and instance variable is 
uninitialized, that fact will be captured. 
If the state is changed while rendering, the new value is not passed on to the 
action phase continuation. 
Hitting refresh or clicking on a link will result in the uninitialized state 
being reapplied. This is consistent in at 
least some sense.

It seems clearer to tell the user that they should not modify any state in the 
render phase than to tell them 
that you *can* modify it but should not do lazy initialization because hitting 
refresh will result in re-
initialization and different instances.

Some of this could be made configurable though, just in case: See Issue 455

Original comment by jfitz...@gmail.com on 5 Sep 2009 at 1:11

• Changed state: WontFix
• Added labels: ****
• Removed labels: ****