This page should give you an overview (in no particular order) about programming pattern you should avoid.
This is pretty straightforward when you're developing in OO-way. You violate the encapsulation if you call a foreign objects private methods, so you should always refrain from doing it.
The point to mention this here again is that calling private methods of other classes can break the build version of a qooxdoo application. Since qooxdoo uses private optimization by default one cannot rely on the names of the private methods of another class. If violate this can end up with a runtime error very difficult to debug.
Do not create multiple instances of a widget which is added/removed multiple times when it is sufficient to e.g. only change the data represented by the widget.
Using synchronous requests will block the whole GUI until the response is received. Always use asynchronous requests to give the control back to the user.
Running intensive tasks on the client should not be an option. Such tasks should reside on the server-side. If it not possible (or not desired) there should be at least a reasonable feedback to the user about the intensive task currently running. If long-running tasks can be split into a sequence of small tasks, the Progressive (qx.ui.progressive.Progressive) widget may allow you to progressive execute the sequence of small tasks without blocking other operation of your application. Organizing your application around a finite state machine (qx.util.fsm.FiniteStateMachine) may also help to avoid the pitfalls of long-running tasks.
Using anonymous inline functions has several disadvantages:
So please avoid using them. :-)
Data fields (every data attached to this) can and should be declared in the members section. This makes it easier to find the data fields, which a may otherwise be deeply hidden in the code.
It is possible to initialize these data fields in the members section with primite data types like String or Number but it should never be initialized with reference types. Reference types are Object (Maps), Array, Date and RegExp. The reason for this is that these references will be shared by all instances of the class. This is typically not the desired behavior. It is better to set the value of these fields in the members section to null and initialize them in the constructor.
BAD:
members :
{
__myArray : [], // <-- don't do this!
__myMap : {}, // <-- don't do this!
...
}
GOOD:
construct : function()
{
this.base(arguments);
...
this.__myArr = [];
this.__myMap = {};
}
members :
{
__myArray : null,
__myMap : null,
...
}
For the same reason reference types should not be used as init values in property definitions.
"requires" in the qooxdoo context are dependencies of a class to other classes which have to be available at load-time, i.e. at the time the class code is read and evaluated by qooxdoo's class factory (currently qx.Class.define). This is in contrast to dependencies which come into play only at run-time of the class code, e.g. when its constructor or member functions are invoked. (Run-time dependencies are usually easy to fullfill since they don't impose an order in which classes are loaded into the browser's Javascript interpreter; in general, they just have to be loaded eventually).
All those possibilities should be avoided or at least used as sparingly as possible. Those requires make dependency tracking difficult and furthermore impedes partitioning the application into parts if this is desired.
qooxdoo comes with a powerful variable optimizer to shrink down the size of your javascript code delivered to the browsers. This optimization is performed with the build version of your application by default. To avoid any runtime errors it is recommended to not name your variables like native browser objects.
Consider the following:
var myIframe = new qx.ui.embed.Iframe(mySourceURL);
...
var document = myIframe.getDocument();
// this piece
document.body.appendChild(myChildNode);
// will end up in "build" version with
p.body.appendChild(myChildNode);
// assuming the "document" variable is optimized with "p" as variable name
We modified the prototype of the array class to add some functions to it, but unfortunately this has a side effect: if you try to loop through an array using a for-in-loop you will not only get the content of the array but also the new functions.
So loop trough an array with an normal loop:
var a = [1, 2, 3];
for(var i=0, l=a.length; i<l; i++) {
this.debug(a[i]);
}