Mutable Persistent Page Properties and ToDo Example

[David Ezzio <de...@ysoft.com>]

Hi,

I'm a newbie to Tapestry.  So far, very impressed both with the code and 
the book.  Good job.  But I am running into one question that I haven't 
found the answer to.

There seems to be a bug or some confusion (perhaps on my part) about 
mutable persistent page properties such as the ToDoList property in the 
ToDo example.

In several places, the documentation says that the attribute should be 
set after it is changed to ensure that HttpSession.setAttribute is 
called.  Everyone seems to agree that making the call to setAttribute is 
required to support clustering.  So far, so good.

The problem arises with the claim in some places that mutable objects 
such as List and Map are copied when set in the page properties, when in 
fact they are not.  As a result, the HttpSession.setAttribute method is 
never called for mutable collection objects unless a new collection 
object is assigned.

In the example, when the enhanced ToDo class's setToDoList method is 
called, the fireObserver occurs, which results in 
PageRecorder.observeChange being called, which results in 
SessionPageRecorder.recordChange being called.

In recordChange, the logic simply gets the old value and then takes two 
steps either of which prevent the HttpSession.setAttribute method from 
being called.

First

	if (newValue == oldValue) return;

Since the List object is passed by reference and not by value, the two 
references are the same, and the method returns.

Second, in the next code block of this method, it does a check on equals 
which would also result in a return if execution passed the first check.

Consequently, HttpSession.setAttribute is not being called in the case 
of the ToDo example as a result of the call to setToDoList in the 
formSubmit listener.

Fixing this bug is an interesting question.  I happen to agree with the 
existing behavior that does not copy List, Map, and Set objects.  In 
many cases, they will not be modified.  Certainly there is no reason to 
copy the immutable objects.

Given that, then I would think the most obvious fix is that 
HttpSession.setAttribute is always called if the fireObservedChange 
method is called.  I don't see a point for the checking in recordChange 
method.



Best wishes,

David Ezzio

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org