Am 02.08.2010 23:44, schrieb Ralf Nieuwenhuijsen:
2010/8/2 Dietrich Streifert <[email protected]
<mailto:[email protected]>>
I've been following your thread. I'm not a qooxdoo developper,
but i'm a bit suprised you don't want to solve the real problem.
Good to hear form someone knowing my real problem. I should stop
paying my couch doctor ;-)
I'm sorry. It wasn't the most diplomatic choice of words.
No problem. I hope you noticed the smiley.
That's not true. The form is reused. The loadtime is on first form
open. Subsequent opening is alot faster.
That's great to hear. So we're talking about the inital loading time
here.
Hmmm... where did you got my source code from? You did not or did you?
I was using some pseudo code. There aren't too many different ways to
actually 'render' a form.
Or are you not using the qx.form.Form class at all?
No. I'm not using qx.form.Form at all. Coming from ancient qooxdoo times
I developed my own xml centric form handling. Fields are "tagged" with
their xml xpath (via mixin). The fields are kept fast accessible via
their xpath by a hash (something like
form.getMapper().getFieldValue('/foo/bar') is very fast). My form
handler called, xml mapper, is xml "aware". The form method setXML which
has xml doc object as parameter fills the form with the values of the
xml doc elements or attributes. More then that there is load and save
which does the complete communication with the backend.
The patient chart is loaded as a single xml-request. So, even if
not visible, values are loaded into fields and cause changevalue
events which have an influence to other fields like disabled
fields etc.
But that part shouldn't take very long.
The actual rendering of all the widgets is another case.
As said before: I suspected the raise in dom creation being the the
performance impact. I'm not sure.
Another area where qooxdoo got tremendous changes is the layout area. I
have to look also into this.
Playground code to prove my case:
http://tinyurl.com/2fnf7a2
>So, even if not visible, values are loaded into fields and cause
changevalue events which have an influence to other fields like
disabled fields etc.
Feel free to create the fields! Just don't /render/ them.
/Don't add them all to the DOM at once!/
In your screenshots I see widgets inside tab-pages.
The only way those widgets can be in a tab-page is if you */add/* them.
So, somewhere in your code, there has to be something like:
myTabPage.add ( myWidget );
All i'm saying is that if you replace that code with:
myTabPage.addListenerOnce('appear', function(
myTabPage.add( myWidget );
});
So let's say I have a tab page which is currently not visible. The form
is opened via the user. After the form is shown the load via xhr is
started and on success my xml mapper starts filling the field values via
their xpath. At this point the fields of the yet hidden tab page are not
instantiated. The initialization fails. OK there is the possibility to
also do a lazy init of the field values after field instantiation of the
hidden page. So I would do a addListenerOnce('appear',...) to every
field instance which does the init from the current loaded xml doc.
Maybe that would be a way.
Sure, in your code it's problely called something other than "myTabPage".
And your code is likely way more complicated than this. But somewhere,
somehow you are adding widgets to a tabpage.
And right there, you replace that code with the 'appear' trick above.
OK I'll have a look into your trick as soon as possible.
I would be really interested in hearing how this trick could possible
be hard to implement in any code-base behind the screenshots you sent
here.
Take a look at the playground code!
- Creating the objects: fast
- Creating the renderer: fast
- Adding the rendered form to the document root: performance hit!
*I'll make you a bet*
If this trick doesn't cut the load time by 80%, I'll drink a German
beer this week ;-)
Don't hesitate! Drink German beer! But you have to choose the right brand;-)
Ralf, I really appreciate your comments and they are very welcome. So
take in account that I'm from Germany and maybe my writing seems little
bit crude compared to native English writers. So I want to apologize for
that. I'm a nice guy;-)
--
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
