commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hans Gilde <hgilde-comm...@earthlink.net>
Subject RE: [jelly] should caching be configurable ?
Date Wed, 29 Sep 2004 02:42:23 GMT
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:paul@activemath.org] 
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


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


Mime
View raw message