Yeah. I would call this a mixin. One way to implement this is as a state which is always applied, but as we've discussed: states are expensive at runtime. Maybe we should add an LFC class that allows you to define this kind of thing but that doesn't extend node. I'd volunteer to do that if people are interested.
A On Dec 20, Jim Grandy wrote: > Since we're in a single-inheritance world, thinking of these pieces of > functionality as separate classes leads to very wide, very deep class > hierarchies with lots of duplicated code and (subtly-different) APIs. My guess > is that there is already enough internal delegate use required to implement > these features that we could adopt an "attachment" pattern much more broadly > in the LFC and the components without losing much performance. > > So instead of a mouseview, we'd have a mouseattachment that hooks itself up to > its parent at construct/init time. > > <view> > <mouseattachment /> > </view> > > The option to ignore subview mouseouts would be declared with the > mouseattachment. > > This seems so well supported with our existing delegate mechanism that I'm > wondering why it wasn't used more extensively in the LFC & components? If it > was considered, why wasn't it adopted? > > (I also want to write a proposal for a compile-time version of this, called > "traits". I haven't been in a hurry to write it because I don't think we can > get it done in the 4.0 timeframe.) > > jim > > On Dec 20, 2005, at 8:17 AM, Adam Wolff wrote: > > > One other thing to note: we could also implement a mouseview class, which > > would be a component that extends view. It could have these properties, > > and it could also fix the clickability problem that Scott Evans emailed to > > this list a while ago. As reminder, the problem is this situation: > > > > <view width="100" height="100" onmouseover="f()" onmouseout="g()"> > > <view align="center" width="50" height="50" > > onmouseover="h()" onmouseout="i()"/> > > </view> > > > > The problem is that g() gets called when the mouse enters the inner view, > > even though this rarely what you want. The workaround for this is usually > > to use the idle loop to check the mouse position to see if the mouse is > > still over the outer view, rather than rely on the built-in onmouseout > > event. This hypothetical mouseview could have a switch to enable this > > behavior. I think I have a mild preference for a new class rather than > > adding to the LFC, but remember: I'm a minimalist ;) > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
