|
»
»
»
« Return to Thread: qooxdoo / PHP framework project
Re: qooxdoo / PHP framework project
by Sebastian Werner
::
Rate this Message:
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: qooxdoo-devel-admin@...
>> [mailto:qooxdoo-devel-admin@...] 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
>> Qooxdoo-devel@...
>> 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
> Qooxdoo-devel@...
> 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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
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: qooxdoo-devel-admin@...
>> [mailto:qooxdoo-devel-admin@...] 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
>> Qooxdoo-devel@...
>> 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
> Qooxdoo-devel@...
> 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
Qooxdoo-devel@...
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
« Return to Thread: qooxdoo / PHP framework project
| Free Forum Powered by Nabble | Forum Help |