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 wish.
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!
paul
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
