tapestry-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cherry Development <...@cherrydev.com>
Subject Re: [Fwd: Re: OJB, Tapestry, Serialized Objects and a quest for answers.]
Date Wed, 05 Nov 2003 06:44:48 GMT

On Nov 4, 2003, at 9:48 PM, Harish Krishnaswamy wrote:

> If you want behavior in your accessors, you will want to create a 
> synthetic property using property-specification and use this property 
> within your real accessor method. For ex.
> public abstract PropType getSyntheticProp(); // property defined via 
> specfication
> public PropType getProp()
> {
> 	...
> 	... getSyntheticProp() ...
> 	...
> }

I'm trying to think of a reason why this is necessary.  Why shouldn't 
the enhanced subclass simply call the base class's accessors if they 
exist and use their default behavior otherwise?  Was this a design 
decision or simply nobody thought of reason why somebody would want 
this?  I assume the problem is that you need two different ways of 
setting these values, one a 'user' method, allowing for special logic, 
and one for 'system' access, for use when page properties are being 
restored from session and need to be set directly.  In WebObjects, this 
is done by allowing for a second set of accessor methods, named the 
same, but starting with an underscore.  I would expect these to only be 
used when the page was being saved to session and restored from session 
and the 'normal' accessors used at all other times.  I know it's rude 
for a newbie to suggest architectural changes to a tool only recently 
picked up, but if I implemented this change, would anybody be opposed 
to it?
> As far as I know, persistent properties may be serialized because they 
> are stored in HttpSession and the container may serialize it for 
> various reasons. Again, I am not sure of OJB, but I have done some 
> work with JDOs and with JDOs you would detach the entity object from 
> the persistence manager before passing it to the page and persisting 
> it there (although I don't like the idea of persisting these objects 
> in the page). And when you want to persist the entity back in the 
> database you would just attach it to the persistence manager which 
> would take care of the rest. Now if this is not possible with OJB, the 
> only thing I can think of is to make a copy of the entity and store it 
> in the page. But I have to say I rarely find myself using persistent 
> properties in my pages. I like to keep  my properties in my pages so 
> there are no synchronization problems between the client state and the 
> session state. So in pageBeginRender I create a hollow object 
> structure that will be populated by Tapestry at the end of the rewind, 
> then I perform my actions in the listeners and set my values in the 
> object structure and Tapestry would read these values and render the 
> page. If I want to update the database with the values from the page, 
> I do so in the listener by querying the object and setting the 
> appropriate values.

I can see different styles of design being used in Tapestry compared to 
what I'm used to.  WebObjects has very few restrictions on what sort of 
objects you keep around on your pages because the pages never get 
pooled.  New ones keep getting created and old ones only get removed 
when they fall off the end of the page cache (the cache is used to 
handle browser backtracking).

If I understand what you're telling me, the ONLY reason my objects 
might get serialized is if the servlet container serializes the 
HttpSession.  If that's so, why does the documentation say that 
Tapestry makes copies of all persistent page attributes when it moves 
them into the HttpSession?  The old documentation states that Tapestry 
explicitly serializes the page state information before storing it in 
the HttpSession.  Is this inaccurate?  What, exactly, does TAPESTRY 
(not the servlet container) do with persistent page attributes before 
and after a request?


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

View raw message