Well... I can't say that I've thought out the semantics of reloading and such, the way you're describing. The current implementation of UseBeanTag and ComponentTag (extends UseBeanTag) never reuse a bean. They always create a new bean every time they're run.
The original impetus for clearing the bean after a run was the fact that the bean would never, ever be reused anyway. If we want to implement functionality the way you describe, we should make it optional. I personally find the create-new-bean-every-time to be the perfect pattern for my own use. It would be quite easy to extend ComponentTag to do what you're saying. It would work like this: Override newInstance() to look in a context variable. If there's a bean, reuse it, else create it and put it in the variable. To re-invoke the tag using your "reload" tag, just navigate to the level that's one above your target level, then call invokeBody. -----Original Message----- From: Paul Libbrecht [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 28, 2004 2:39 AM To: Jakarta Commons Developers List Subject: Re: [jelly] should caching be configurable ? Le 28 sept. 04, à 02:02, Hans Gilde a écrit : > Here's the memory "leak" that was fixed by nulling out the component. > It's not so much of a leak as a "holding on to references that should > be available to the GC": > > I might want to build several instances of a JFrame from the same > Jelly script. But, I may not. I may simply keep that Script around but > never end up using it again. > > Let's say that my frame uses lots of memory. I build a frame using my > script. Now that script has a reference to my frame. I dispose of the > frame, but I don't end up creating another one. > > I expected that my frame would be available for GC, but it wasn't > because it's still referenced by the script that I'm keeping around > just in case. I'd rather find the converse natural: - the script should be rebuilt if need be - but if the script (or some snippets) is re-run, I'd like it to re-run with its original beans... My little reload-tag does the following and I think it's quite appropriate. Basically, it considers each component-tag as a browser frame. <swing:panel> <!-- some content --> <swing:button><swing:action name="Do"> <swing:reload level="2"/> </swing:action></swing:button> </swing:panel> When the Do button is pressed, my reload tag empties the content of the panel and re-runs the body-script which re-populates the panel depending on an XML-document which got updated by this GUI. (I am using Xwing, a typical example is to have a forEach inside the panel that iterates on children, the reload is wished when you add something and where the forEach should be re-run). I know there are ways out differently (instead of the reload, actually execute a tag or function which does the population) it's just, much more elegant, I feel! paul PS: there's a taste of browser-DOM-connection out there... maybe it's good, or not... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
