Hello Dietrich,
I've managed to migrate my app from qooxdoo 0.7 (branches/legacy_0_7_x/qooxdoo)
to 1.2 pre (trunk) and after a hard battle and some refactoring it works.
Congratulations! Thats good to hear for us. :)
This means we have a LOT of input fields. In the patient chart we have approx.:
110 checkboxes
260 radiobuttons
100 textfields/textareas
44 comboboxes
Thats really quite a lot! You are showing all these elements at the same time
in one form? If not and you are showing the forms in separate tabs foe example,
you can delay the creation of the tab e.g.
Here some manually measured times for the first opening of the window (dom
creation and data loading):
qooxdoo 0.7 qooxdoo 1.2pre
FireFox 3.6 ~1sec ~3 sec
IE 8 ~2 sec ~9 sec
For FF 3.6 the additional 2 seconds are not dramatic but for IE 8 waiting
additional 7 seconds for the first start of the form is not acceptable.
About 9 sec is really too much and not acceptable. I fully agree with you!
There is no benefit for my customers in using the qooxdoo 1.2 version of the
app. This gives no additional functionality, quite the opposite: it is, from
their impression, MUCH slower. Additionally checkboxes and radiobuttons are to
small compared to the native checkboxes and radiobuttons in 0.7.
The benefit for the developer should be one of the key things. If you continue
the development of the app, you will sure be faster in developing. But you are
still right, the app needs to be at least as good as the old one.
I took a look at how form fields are rendered in qooxdoo 0.7 and compared that
to 1.2pre. I noticed the following differences regarding the number of created
DOM elements:
qooxdoo 0.7 qooxdoo 1.2pre difference
checkbox 2 DIV, 1 INPUT 6 DIV, 1 LABEL 4 elements
radiobutton 2 DIV, 1 INPUT 6 DIV, 1 LABEL 4 elements
textfield 1 DIV, 1 INPUT 4 DIV, 1 INPUT, 1 LABEL 4 elements
The 1.2 numbers are worst case. I checked the textfield and there are some
elements only created on demand. Maybe you have a worst case scenario?
Are my thoughts regarding the increase in execution time reasonable?
We are aware of that. We added a lot of new features since 0.7 which caused the
increase of the DOM elements. As you can see, the checkbox and radiobutton is
now fully themable which was not possible with the 0.7 once. Still, we have a
open bug report to check if its possible to reduce the number of DOM elements
to speed up the rendering:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=3548
How can I reduce the amount of created dom elements?
I think there is not much you can do about it when you continue to use the
default qooxdoo widgets.
Why does a textfield use additional 4 dom elements in 1.2pre compared to 0.7?
Fabian held a good presentation about how widgets are created in qooxdoo at the
last years jsconf. Take a look at his slides:
http://www.slideshare.net/fjakobs/autopsy-of-a-widget
He explains using a textfield how and why something is created.
Is it possible to re-implement native checkbox and radiobutton widgets from qx
0.7 as a replacement of the 1.2pre versions?
Sure, custom widgets are always possible and quite easy to implement. I took
some minutes to get an example checkbox running in the playground. Its not much
but you see that its working and only using one div and one input:
http://tinyurl.com/3ab2ttm
Regards,
Martin
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
