commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: [jelly] should caching be configurable ?
Date Tue, 05 Oct 2004 09:07:22 GMT
Things are hairier as I thought, way hairier!

I did it as you suggested but it turns out it's still trying to add to 
a component-tag's bean that's null. It seems that findAncestorWithClass 
creates new tags spontaneously but not necessarily configuring them 
enough (in this case, having a null bean).

I have been trying all sorts of things possible but I am still not 
understanding clearly how are tags, scripts, and beans created and 
destroyed... if there was a systematic in there, I'd really enjoy 
reading about it.

I also tried caching a reference to the tag... didn't work.

Oh, and of course tried, what everyone would suggest: use define (or 
xwing's "func") to make the script that populates the component so that 
it gets reinvoked. Unfortunately, jelly-swing tags really hunt hard for 
their parent along the tag hierarchy which, of course, is not what they 

I have more and more the impression that this old thread about making 
Jelly functional, with a return value being part of an extended 
XMLOutput would make things so much simpler!


Le 29 sept. 04, à 04:42, Hans Gilde a écrit :
> 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.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message