Re: Overview of behavior attachment as a general problem on the Web

On Sat, Jul 9, 2011 at 1:42 PM, John J. Barton
<johnjbarton@johnjbarton.com>wrote:
[...]

> The Behavior Attachment Methods section is also super, but at the end I was
> puzzled. I thought the Shadow DOM proposal only allowed one binding, and
> thus it would exclude exactly the Decorator pattern we need to compose
> multiple frameworks.  I understand how you can solve the Dojo or Sencha or
> jQuery problem better, but I don't see how you can solve the 'and' version.
>

IMHO there is a difference between altering the functionality of a component
or decorating it. In the first case you need deep knowledge of the
component's internas and thus cannot afford a random order in the
inheritance chain.

OTOH, in the decorator case you are explicitly not interested in internas,
and have no control over order of application. I would therefore argue that
inheritance (as, e.g., proposed by XBL2) is the wrong vehicle for
decoration. For example, what if a decorator omits the <inherited> element
in its tree? It seems to me it should be sufficient to only give a rough
outline where the decoration should go, perhaps similar to CSS's ::before
and ::after.  Conversely, a decoration should _not_ be able to see, or even
modify, anything inside the original component, nor use <inherited> or
<content>.


Cheers,

- Roland