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" >

    <view align="center" width="50" height="50" 

          />

</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

Reply via email to