I steer away from the word "mixin" because it has such strong meaning
in the context of multiple inheritance. I think "attachment" is
better because it connotes, well, the attachment of one object to
another to modify behavior.
I've seen code in various places in the LFC and components that
creates event handlers with reference attributes to hook into events
in a parent view. Granted it is manual, not automatic like states,
but couldn't this technique be used to build attachment classes that
simply register for events at initialization? The restriction would
be that you couldn't override methods, but for certain applications
(like your mouseview example) this might be enough. Also, it seems to
me that this would be not much more expensive than adding an event
handler directly in a class declaration.
Having an LFC class that doesn't extend node kind of scares me unless
we create an LzObject that everything can extend. I already don't
like it that we have LzDataNode and LzNode as separate class
hierarchy roots! (But we've already discussed that.)
jim
On Dec 20, 2005, at 9:40 AM, Adam Wolff wrote:
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
