RE: Recommended way to clean up a component?

I like Geoff's suggestion. In fact, that is what we already do in our base 
page class.

>PageDetachListeners always and just have a detach() method like pages?

There are 2 problems with this approach.

1) There is a potentially very large number of components on a page and 
there is no point in adding needless overhead to message all those 
components if they are not interested in the event.

2) Having a class implement an Interface is not only a run-time/compile-time 
artifact, but it is also a valuable design signal. You are signalling that 
this class is special in some way because it implements this interface. You 
can use these cues later on when you are trying to figure out where 
something is happening. It is also a signal to other developers that 
something a little out of the orginary is going on. And by other developers, 
I also mean the original developer 6 months after the initial code write, 
when that developer is trying to figure out what the hell he was thinking 6 
months earlier ;)

joe
Joseph Panico
[email protected]




>From: Phil Surette <[email protected]>
>To: "'Geoff Longman'" <[email protected]>,        "Tapestry 
>Developer (E-mail)" <[email protected]>
>Subject: RE: [Tapestry-developer] Recommended way to clean up a component?
>Date: Mon, 11 Nov 2002 10:21:30 -0500
>
>...or something more obvious.
>
>To me, the differences between pages and components should be minimized
>whereever possible, since in the course of refactoring your app you often
>extract components from pages. Why not have components be
>PageDetachListeners always and just have a detach() method like pages? Is
>there a problem I'm not seeing, or is this just a usability tweak that has
>been overlooked?
>
>-----Original Message-----
>From: Geoff Longman [mailto:[email protected]]
>Sent: Monday, November 11, 2002 10:11 AM
>To: Phil Surette; Tapestry Developer (E-mail)
>Subject: Re: [Tapestry-developer] Recommended way to clean up a component?
>
>
>By looking at the Vlib example your following the pattern.
>
>I would suggest that explicity registering a DetachListener should not be
>required. Could not the framework recognize that a component
>implements PageDetachListener and just register it? That would save
>developers from having to override finishLoad().
>
>Geoff
>
>----- Original Message -----
>From: Phil Surette
>To: Tapestry Developer (E-mail)
>Sent: Monday, November 11, 2002 9:30 AM
>Subject: [Tapestry-developer] Recommended way to clean up a component?
>
>
>I have some components that retrieve and store a copy of a db object in a
>local variable which is accessed many times by the component. The object is
>lazily loaded like this:
>Object getCachedDBObject() {
>         if (m_cachedDBObject == null) {
>                 m_cachedDBObject = retrieveObjectFromDB();
>         }
>         return m_cachedDBObject;
>}
>At the end of the current cycle, m_cachedDBObject needs to be nulled out so
>the next time the component is used it'll get a new copy.
>What's the best way to do this? Right now I'm making my components 
>implement
>PageDetachListener and override finishLoad() like this:
>public finishLoad() {
>         getPage().addPageDetachListener(this);
>}
>public void pageDetached(PageEvent pageEvent){
>         m_cachedDBObject = null;
>}
>Is this the right way to do it? Is there a better way? I tried overriding
>cleanUpAfterRender but that didn't seem to work... could easily have been
>user error though.


_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf