Re: Overview of behavior attachment as a general problem on the Web
On Sat, Jul 9, 2011 at 1:42 PM, John J. Barton 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 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 or . Cheers, - Roland
Re: Overview of behavior attachment as a general problem on the Web
On 7/8/11, Dimitri Glazkov wrote: > As a background for the wider Component Model discussion, I put > together an overview of the general behavior attachment problem on the > Web: > > http://wiki.whatwg.org/wiki/Behavior_Attachment > > Please take a look. Comments, additions, and critique are appreciated. > I read: "In Web applications, the lack of proper behavior attachment method is addressed at a library level, with every Javascript framework attempting to solve this problem. Here is a quick overview of approaches: " Looks like a summary of inexperience. The examples under the heading "Extensions" do not work in Firefox 5. Instead, I get the error message displayed "Sorry, we don't support your browser just yet. You'll need Google Chrome to install apps, extensions and themes. [Link: Download Google Chrome]". Browser detection error message displayed on a web page full of HTML errors and code that looks like Google's new badly implemented "+1" idea. I'd say get some more experience. It's great to share ideas but you should learn about how to build web apps, and do that, and then get those apps reviewed by experts -- and I don't mean your Google coworkers. -- Garrett
Re: Overview of behavior attachment as a general problem on the Web
On 7/8/2011 1:18 PM, Dimitri Glazkov wrote: As a background for the wider Component Model discussion, I put together an overview of the general behavior attachment problem on the Web: http://wiki.whatwg.org/wiki/Behavior_Attachment Please take a look. Comments, additions, and critique are appreciated. :DG< First, I like the overview, I think it helps clear up a lot of issues. And it raises lots of questions, which is also good ;-). I'm not quite connecting the dots. Behavior attachment is needed, your examples demonstrate that. You claim the missing facility is atomic component addition and proper encapsulation. Perhaps this is well known, but I think it would be helpful to explicitly explain why organized behavior attachment requires encapsulation. Actually I think a better approach is to explain why/how behavior attachment with encapsulation will be better, cheap, faster. A small example would be helpful (perhaps later in the document). Your introduction highlights encapsulation. However, it seems to me that encapsulation is secondary to componentization: the critical step is to have a way to group HTML/CSS/JS in to a unit that can be developed independently and then be used without reference to the implementation. Encapsulation in the the OO sense adds constraints that enforce the boundaries. It's great and maybe even critical but not primary. The examples sections are great, perhaps some experts will correct some details but your overall approach here is excellent. 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. HTH, jjb
Overview of behavior attachment as a general problem on the Web
As a background for the wider Component Model discussion, I put together an overview of the general behavior attachment problem on the Web: http://wiki.whatwg.org/wiki/Behavior_Attachment Please take a look. Comments, additions, and critique are appreciated. :DG<
