Hello Martin,
thank you for your answers and hints.
Am 30.07.2010 11:53, schrieb Martin Wittemann:
Hello Dietrich,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.
Currently the fields are stacked in five main tabs with a total of 15
subtabs. And yes, they are all created at the same time. Delayed
creation of the tab contents is something I want to investigate.
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.
No dought! I fully agree with you. I see the tremendous progress between
0.7 and 1.2.
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?
I'll have a look further into dom creation. Especially there are a lot
of checkboxes and textfields which have no label, the label is created
elsewhere. This is due to the fact that labels are arranged right
aligned within a grid layout and fields left aligned.
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
I've added me CC to this bug
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
This is what I considered as a main performance tweak: creating some
lightweight version of checkbox and radiobutton where input tags are
used instead of selfrendered buttons. I need of course the value/model
property and the changevalue events, I need to be able to disable/enable
the widget and so forth. Radiobuttons should be manageable by
readioboxes etc.
We'll see if I can "afford" this work.
--
Mit freundlichen Grüßen
Dietrich Streifert
--
Visionet GmbH
Firmensitz: Am Weichselgarten 7, 91058 Erlangen
Registergericht: Handelsregister Fürth, HRB 6573
Geschäftsführer: Stefan Lindner
------------------------------------------------------------------------------
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
