commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Libbrecht <>
Subject Re: [jelly]
Date Thu, 07 Oct 2004 06:54:21 GMT

Le 7 oct. 04, à 02:23, Dion Gillard a écrit :

> On Wed, 6 Oct 2004 15:18:50 +0200, Paul Libbrecht 
> <> wrote:
>> Gee... I was really thinking this was obvious... hence the relatively
>> undetailed descriptions.
> Obviously it isn't for me. It seems to me that you want to use
> XMLOutput to pass data around, even though it's currently a
> 'write-only' object, i.e. there's no way of getting of data back out
> of it.

The read-write paradigm is really old fashioned.
What I have in my component-tag inside the invokeBody(xmlOutput) is 
(with a simplification):

   super.invokeBody(new XmlOutput(xmlOutput) {
     public void objectData(Object b) {
         if(b instanceof Component) {

That's not really reading or writing, it's just catching!

>> - XMLoutput objects are exchanged as part of the doTag nested calls.
>> Therefore it is easy for something aimed at "receiving data" to create
>> an XMLOutput object that does something just for the data() call, and
>> passes-through for the rest.
>> This way a tag can receive a return value.
>> There's no way to do so with the context except delicate hacks and
>> fragile naming-conventions.
> Sounds like hand-waving. Obviously tags return values, e.g. the set 
> tag.

Tags don't return values, tag only write values in the context.
A returned value could be used in further functional composition.
Further composition of a value in the context needs to name it (and 
manage its deletion in some way).

> Isn't the context for passing stuff around?


>> - to me, it makes loads of sense to have tags that transform their
>> output... and that should apply to object-data as well. (so that 
>> adding
>> a constraint in jelly-swing would be simply a transformation)
> Tags that transform their own output? Or output from nested tags?

output of nested tag.

>> At least, to me, it is the only way for a component child, like a 
>> swing button, to talk flexibly to a component container, without 
>> manually walking the hierarchy.
> Hmmm. *Only* way seems to be a little exaggerated. Can't the component
> have it's parent set at some time later?

Well, I really tried hard in all sorts of way and didn't manage it.
The notion of parent is not well defined if you want to re-use 


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

View raw message