I think the main value of using XUL is to borrow from a standard that has many UI-related challenges solved using standard patters as Ben mentioned. There are also a host of tools starting to spring up to edit XUL definitions. Even visual drag and drop tools to design UI's.
Using the QxBuilder syntax will work, but it may get pretty verbose when you start to link many components together with events. Do we have to have the XUL engine on the client side? It would be ideal, but it would further slow down loading of qooxdoo apps. Can we not implement a server component that will take the XUL definition and generate all necessary javascript that qooxdoo will need and simply have qooxdoo load it into its context. I can write such a converter initially in PHP pretty quickly. There would be a client javascript component to it as well that will call event callbacks with a context more comprehensive than qooxdoo currently provides with its event system. This comes back to the question of how qooxdoo code should be defined to maximize speed of loading. Is the API the fastest way or would it be faster to load some king of internal structure? Christoph -- View this message in context: http://www.nabble.com/qooxdoo-PHP-framework-project-t1389226.html#a3768945 Sent from the qooxdoo-devel forum at Nabble.com. ------------------------------------------------------- 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
