Hi All!
I just want to throw something inside this thread. Completely unspecific
to this current message ;)
Have you all thought about to just contribute to one of the newly
upcoming "Rapid Development Frameworks" instead of creating a new one.
For PHP:
http://phpontrax.com/
http://cakephp.org/
http://www.symfony-project.com/
For Python:
http://www.djangoproject.com/
For Ruby, sure:
http://rubyonrails.org/
I think these frameworks could be really well used (after some work) to
build qooxdoo applications. In my opinion it's more than just create a
interface.
Also I think to have a xml markup to describe the interface is a good
idea. That's really great I think. There are different possibilities to
implement this:
1. Send the XML to the Client and let QxBuilder transform the XML to
JS-Code (maybe to slow)
2. Send the XML to the Client and let XSLT (client locally) transform
the XML to JS-Code (should be faster than option one)
3. Convert the XML at server side to JS-Code. Using XSLT or some other
language. (This results in my opinion to big JS-Code you must transfer
to the client.)
4. Convert the XML at server side to JSON. Using a new qooxdoo class to
transform this JSON code to JavaScript objects. (In my opinion the best
choice. The code which needs to be send to the client in relatively
small and also it's possible for the client to render this stuff really
quickly.)
Just my 2 cents.
Sebastian
Priebe, Jason schrieb:
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=k&kid0944&bid$1720&dat1642
_______________________________________________
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&kid=110944&bid=241720&dat=121642
_______________________________________________
Qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
