CODEWITHSUNDEEP
javascriptqooxdoo
Stelios Joseph Karras
Stelios Joseph Karras

Reputation: 483

qooxdoo create widgets with specific id

I have been playing with qooxdoo almost a month now and I am pretty excited with this little beast ;) .

Now I am trying to create any widget with an id , I have find a way to manage child widgets with the Class Composite (http://demo.qooxdoo.org/current/apiviewer/#qx.ui.container.Composite)

but I cannot find a way to create a child with specific id like 

var textfield1 = composite.add("triggerOne");
textfield1 = new qx.ui.form.TextField();

the only way is over a protected method in widgets class but this supposed to be exposed in the composite class ? (http://demo.qooxdoo.org/current/apiviewer/#qx.ui.core.Widget~_createChildControl!method_protected)

Upvotes: 0

Views: 988

Answers (2)

Stelios Joseph Karras
Stelios Joseph Karras

Reputation: 483

I use setUserData to set an identifier field on each object that I want to identify with an id http://demo.qooxdoo.org/current/apiviewer/#qx.core.Object~setUserData!method_public

Upvotes: 0

ArnisAndy
ArnisAndy

Reputation: 336

That method is used by controls that directly extend Widget() to allow the use of id's. The id's allow child controls/widgets to be accessible to controls that might contain the Widget (which is likely why you need it.) It also helps ensure that the child controls are disposed-of correctly. I'm not aware of a way to assign an id to controls/widgets added to a Composite-like control.

In my experience creating objects that extended qx.ui.container.Composite (or GroupBox or TabView or ...) requires assigning the contained widgets to a member variable if you need direct reference to them again. Keep in mind, too, that when extending a Composite-like object that (if you are going to be creating and destroying them often as part of your interface) you will need to keep an internal reference to the contained widgets. This reference will be used so that you can clean up after yourself in the destructor:

http://qooxdoo.678.n2.nabble.com/Memory-Management-best-practices-in-composites-td5325700.html

On way is to use a member array and push each child widget into the array. Then use this._disposeArray() in the destructor. I've been bitten by memory leaks in Composite based widgets when I did not use this technique. (I had some long-running web interfaces that needed to be good citizens.) The underlying Widget() class from which Composite-like controls inherit actually keeps it's own internal array to do the same, but it's an internal implementation subject to change (and thus you'll want to keep you own.)

If you want to use specific id's you'll need to extend the qx.ui.core.Widget (instead of Composite-like controls.) Check the many examples in the qooxdoo SDK. See qx.ui.groupbox.GroupBox() as an example.

If I understand it correctly, the primary difference in implementation between extending the Widget vs. the Composite-like classes is the use of the id's in Widgets and the benefit that as long as you add the child controls via an id they will be automatically "cleaned-up" in the destructor. The downside to Widget based controls is that they tend to require a little bit more mental effort in planning them out vs. the code-and-go method that Composite-like controls do. I often start with a Composite-like control and then update them to be an extended widget if I find I'll be re-using them a lot.

Upvotes: 1

Related Questions