Re: shadow nodes and event binding

I think that the only things that you wouldn't be able to do with a
Javascript implementation of an XBL would be obscuring the shadow
trees, especially if you implement your own AnonymousElement methods
(easy enough to do with XPath), and then deal with the problem of id
collision by using an anonid type attribute. It's not perfect (in
fact, its more than a bit of a kludge, even in Mozilla) but this
should also make it possible to create the requisite change events,
unless I'm missing something really profound here.

I'd also recommend taking a look at the extant XForms implementations,
especially something like Orbeon. The XForms eventing model is not
that different, and I could see adapting the code they've developed to
handle a more generalized XBL.

-- Kurt



--- In xbl-developers@yahoogroups.com, Cameron McCormack <cam@...> wrote:
>
> Jeremy Bowers:
> > Interesting. If I'm reading the definition of "shadow tree" correctly,
> > I consider it one of the *advantages* of XBLinJS that it uses *real*
> > nodes and not half-implemented "shadow" nodes.
> >
> > My experience was with Mozilla around 1.7, and the shadow node
> > implementation was disasterously buggy, compared to real nodes.
> >
> > Can you tell me why you *need* "shadow trees", rather than real DOM
> > nodes created via createElement?
>
> In a word, encapsulation. Having the shadow nodes inside a shadow tree
> that is connected to the element, and not in the real DOM, affords some
> level of encapsulation. True, it's not that well encapsulated because
> you can always get to the shadow content through an attribute on the
> bound element, but it does keep the implementation elements separate
> from the main DOM.
>
> > (My goal with XBLinJS is to have a *real* feature match with XBL, not
> > to match implementation-detail for implementation-detail. If "shadow
> > nodes" are just "how it's done" and not an actual feature of some kind
> > providing direct benefit to the end programmer, I don't consider "it's
> > missing shadow nodes" to be a valid criticism.)
>
> Sure, I don't think shadow trees are really necessary for
> form/presentation separation. It's just a bit cleaner, IMO. Especially
> when you have nested bound elements.
>
> --
> Cameron McCormack ICQ: 26955922
> cam (at) mcc.id.au MSN: cam (at) mcc.id.au
> http://mcc.id.au/ JBR: heycam (at) jabber.org
>