Re: Wrapper templates

> The final description by Adam of Child Wrappers is:
> http://lists.xwt.org/pipermail/dev/2002-September/001082.html
> 
> Off the example in that mail, each child of $target would actually be 
> an instance of org.xwt.foo. Each instance of org.xwt.foo would have one 
> child, which is the box originally added to the parent of $target.
> 
> That description was pretty confusing, but that's how it stands.

Thanks for the link.

It looks functional... but a little confusing:

// $target[0] returns wrapper around first child
// thisbox[0] returns first child (box *inside* the wrapper)

This isn't the most intuitive approach, and will be very confusing to those
who are looking at code and don't appreciate how it works.

An alternative might be something along the lines of:

$target[0] // returns the first child
thisbox.redirect.wrapper[0] // returns the wrapper around the first child

> This listener is an interesting idea, not so much as a wrapper, but as 
> a natural extension of redirect.

It would negate the need for a 'redirect.xwt' and is fairly logical.

I'd be happy to see it go into the engine.  Adam?

> I suppose the argument against it is you can get the same functionality 
> by reusing a 2-line function

Yeah, it's not as simple or elegant, but it works.

> I'm just not sure if the cut down code is worth the extra complexity 
> this brings. Would a _variable1 trap in the parent template be called 
> if the redirect is listening? If so, would it get called before 
> $inner._variable1? I would suggest the answer to be yes to both.

Sounds right.

> arguments.trapname

I never knew that one existed... the 'arguments' object is woefully covered
in the XWT reference, with it's explanations of it's various properties
being strewn around various parts of the reference, and (I just checked)
arguments.trapname is not covered.
_______________________________________________
http://lists.xwt.org/listinfo/dev