Bugs item #608768, was opened at 2002-09-13 02:09
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104754&aid=608768&group_id=4754
Category: Tapestry
Group: bug
Status: Open
Resolution: None
Priority: 5
Submitted By: jason owens (jlowenz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Changes saved AFTER IPage.detach()
Initial Comment:
If one creates a new object in a page constructer (e.g.
a HashMap for tracking sparse changes to a list), and
proceeds to call fireObservedChange("hashmap", hashmap)
when a value is added to that hashmap, the expected
behavior is that the hashmap will be saved into the
session for use during form rewinding, etc...
However, consider that instead of setting this hashmap
null in the detach() method, we only want to clear() it
for the next time around: so we call hashmap.clear() in
the detach() method.
The result is that your data will NOT be observed,
since it is being saved to the session AFTER the page
is detached (and thus results in a cleared hashmap).
There are two ways around this: do not modify the
object in detach(), instead just null it and create it
new next time the page is loaded (where do you do that,
BTW?) OR send a clone() of the map to the
fireObservedChange method.
It is very confusing when you expect to be able to do
any kind of initialization in the detach() method.
----------------------------------------------------------------------
>Comment By: Howard Lewis Ship (hship)
Date: 2002-12-29 15:13
Message:
Logged In: YES
user_id=26816
This is in progress for 2.4. Tapestry will make copies of
persistent objects and store the copies. When rolling back
changes, it makes copies of the stored values and uses
those to restore the page state.
Immutable objects (String, Number, etc.) are not copied.
There's also some fudging for EJBObject so that an
EJBObject reference can be persisted (effectively, the
EJBHandle is what gets stored).
There's new interfaces and classes for dealing with copying
and persisting objects. There's a new extension point for
overriding the default.
----------------------------------------------------------------------
Comment By: Howard Lewis Ship (hship)
Date: 2002-11-28 10:06
Message:
Logged In: YES
user_id=26816
I don't think this will make it into the 2.3-alpha-1.
----------------------------------------------------------------------
Comment By: jason owens (jlowenz)
Date: 2002-09-16 12:30
Message:
Logged In: YES
user_id=505033
That would be great. Thank you.
----------------------------------------------------------------------
Comment By: Howard Lewis Ship (hship)
Date: 2002-09-15 21:25
Message:
Logged In: YES
user_id=26816
I think your comments are correct. I've been allowing users
to "fudge" a little, but storing mutable objects as properties
and allowing the page to "share" the mutable object with the
page recorder.
In reality, the page recorder should identify what it considers
mutable objects to be, and make its own copies of those
objects in an adaptable way. If the page makes more
changes to the mutable objects, they should have to perform
more fireObservedChange()s.
These are more disruptive changes than I want to make at
this stage of 2.2 ... I would prefer to do this in 2.3.
----------------------------------------------------------------------
Comment By: jason owens (jlowenz)
Date: 2002-09-13 10:24
Message:
Logged In: YES
user_id=505033
The theory makes sense - except that in theory one also
expects the changes to be observed when you actually fire
the changeObserved event, and one doesn't expect that the
detach() method would affect anything that happened in the
render.
To defend myself, I am following the documentation - by
clearing the hash, and *not* setting it to null, the page is in
the same state as it was immediately after creation (since
the hash was initialized in the constructor). However, it
seems that Tapestry's assumption is that I will create new
objects for each request (by assigning a new HashMap in the
detach() method). I was simply trying to bypass this object
creation, by storing the data in the user's session (because it
*is* a persistent property) and then reusing the same object
for the next request. Maybe it's a stupid and useless
optimization, but I think I was misled by the theory. Pages
are *not* serialized when they are put in the pool are they?
I suppose the main point is that I'd like the serialization of
observedChange events to be carried out before the detach()
method is called (I don't think that would break any
documented semantics...). Either that or just add this as a
warning for developers in the documentation. I suppose now
that I know about it, it's not that big of deal. The hard part was
finding out.
----------------------------------------------------------------------
Comment By: Howard Lewis Ship (hship)
Date: 2002-09-13 07:02
Message:
Logged In: YES
user_id=26816
The way persistent page properties work is that the page
recorder holds a reference to your object. In theory, you
should not make changes to persistent properties once the
render takes place.
In your situation, just set the property to null inside detach().
On a later request cycle, the recorder will restore the property
from the retained instance.
Looking at your example ... does the Map have to be page
persistent? It sounds like you want to clear it out at the end
of the request cycle ... thats a transient, not a persistent,
property.
Again, the documentation for detach() is that it returns the
page to the same state as it was immediately after creation.
I'd like to close this bug, I want to hear your response first.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=104754&aid=608768&group_id=4754
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Tapestry-developer mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/tapestry-developer
