Hello Derrell
Yes, after your explanation it makes your point more clear ;) Thank you.
But isn't the order of the constructor-calls independent of this?
I thought about the qx.Class.include() approach as well but I decided against
this for the following (personal) reasons:
If one uses the qx.Class.include() approach, I assume that the calling of the
Mixins methods will also be in the area of the instantiation
<pre class='javascript'>
// ...
initGUI : function () {
// ...
qx.Class.include("app.ContextTable", "qx.ui.table.MTableContextMenu");
var table = new app.ContextTable(tableModel);
table.setContextMenuHandler(0, this.__contextMenuHandler, this);
// ...
},
__contextMenuHandler : function (/*...*/) {
// ...
}
// ...
</pre>
With the "__contextMenuHandler" being a method of the calling class, which is
something I would not expect.
And the app.ContextTable class definition would shrink into something like:
<pre class='javascript'>
qx.Class.define("app.ContextTable", {
extend : qx.ui.table.Table
});
</pre>
Still, I don't think the constructor-call order is the best as it currently
is.
I will just try to swap the constructor-call order of my local framework copy
(qx.Class.__wrapConstructor lines 1618 - 1638) and see what happens...
Maybe I get a feeling if this does more harm than help :-D
Stay tuned for any results...
Peter
On 2010-12-16 15:29 Derrell Lipman wrote:
> On Thu, Dec 16, 2010 at 09:18, Peter Schneider <[email protected]>wrote:
>
>> Hello Derrell,
>>
>> thanks for the reply, but I think I don't get it. Probably I misunderstand
>> your
>> arguments.
>>
>> You say that qx.Class.include() can be used as well. I agree, but what
>> would
>> be the difference to the "direct" include?
>>
>
> You had copied, from Ralf's post, "But the class using the mixin knows its
> using the mixin." That's not the case when qx.Class.include() is used to
> attach a mixin to a class. The class may have no knowledge at all that the
> mixin is attached to it. Rather, users of instances of that class know that
> the mixin features are available.
>
> That's why the class can't assume that the mixin is available in this case.
> In the case with the include member of the class definition it could make
> that assumption, but then you'd have two different orders of operation which
> couldn't be counted on.
>
> Does that make more sense?
>
> Derrell
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
