> Oliver Vogel wrote:
>
> > what still needs to be debugged are <qx:script> sections,
> this might
> > be a problem when compressing the code.
> That's exactelly what i mean, the GUI is IMHO no problem but
> a "normal" app has not only gui, it has some kind of functions!
> And how to debug them inside XML (how to set a breakpoint for
> example - in pure JavaScript this is no problem but INSIDE XML???)
I agree with Olli. I started down the road of a PHP framework that
would have classes corresponding to the QX classes. You could assemble
a UI in PHP, then ask it to dump the Javascript. I gave up after a
week or two.
I now treat my client-side code as a standalone client application
that uses Sajax to communicate with the server. This model is a lot
easier for me to work with.
Here are the two biggest problems I had with trying to generate the
Javascript in server-side PHP:
- specifying event handlers is horrible -- you have to include big
blocks of Javascript code in your PHP (or in the proposed system,
in the XML). Coding Javascript is tough enough with the current
tools, and doing it inside of another language's development
environment doesn't make it easier. The bulk of my application's
code is event handlers, Sajax calls, and callbacks.
- managing variable names of the widgets is pretty awful, too --
your events will presumably want to modify or add data to the
widgets -- how will they refer to the widgets?
- you can't make a layout property of a QX widget dependent on a
layout property of another widget, because the actual Javascript
QX widgets (and their layout behaviors) don't really exist yet.
I don't think that these issues are insurmountable -- I just think you
should give a lot of consideration to them before investing too much
time.
Good luck!
Jason Priebe
CBC New Media
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
>
>
> >
> > My test case to compare QxBuilder and a server-side
> solution is a huge
> > widget with 5 tabs, 10 Textareas and 30 -40 textfields. With
> > QxBuilder, it takes 10 or more seconds to build the widget
> and I get a
> > script timeout warning unless I insert some setTimeouts. I
> hope that
> > pure javascript will be a bit faster - but to be honest, I
> don't know.
> > I have so far simply assumed that this would be the case.
>
> I think, javascript is even faster (many times faster) than
> parsing XML
>
> So i think, it is better to make a "offline" compiler -> just
> write the
> (error-free) XML and generate a javascript-script.
> The GUI is then ready (and error free and easier to make than
> writing code by your own) and than you can beginn to fill the
> functionality (and if this is ok copy it back to the XML - if
> you like) so that you can do the generation more than once)
>
> Olli
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking
> scripting language that extends applications into web and
> mobile media. Attend the live webcast and join the prime
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&;
> dat=121642
> _______________________________________________
> Qooxdoo-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
>
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
