I would agree. If I wanted a page oriented framework I would use Ruby on Rails. With Qooxdoo the archiac notion of a page based navigation is a thing of the past. I for one, don't ever plan to go back to page based nav. ;)
________________________________ From: [EMAIL PROTECTED] on behalf of Jim Hunter Sent: Tue 4/11/2006 12:52 PM To: [email protected] Subject: Re: [qooxdoo-devel] QxBuilder + Server-side integration ideas I for one would vote against such a change. There are plenty of JavaScript 'toolkits' out there that do this very same thing. The reason I choose Qooxdoo was because it is a true application framework where I can write full featured applications without thinking in terms of 'web pages'. My application has one page, and there is no HTML on the page. Everything is done the same way you would write any normal application, via events. Adding a parsing layer to the toolkit would add more size to the footprint that (IMHO) is not needed. Just my opinion, I could be wrong. Jim On 4/11/06, Jose Henrique Steckelberg F. <[EMAIL PROTECTED]> wrote: I've been following qooxdoo devel for some time, and would like to propose something which is somewhat related to the PHP framework discussion thread: could dojo's way of "templating" applications be implemented in qooxdoo? QxBuilder should be able to read the page's html at onLoad and parse its contents, changing it dinamically for QxWidgets by means of innerHtml/outerHtml, but only those specifically tagged, and leave the rest untouched, so the page's html could turn into its own template and content at the same time. Something like: <html> <form> <input qxWidget="qxInput"/> </form> some text here <div qxWidget="qxTree" icon="..." title="..."> <div qxWidget="qxTreeFolder" title="..." > <div qxWidget="qxTreeFile" title="..." > </div> </div> </div> some text there </html> QxBuilder could read and modify the page above, so each tag with qxWidget attribute would be switched for it's corresponding qxWidget, with it's attributes set from the html source too. Benefits: 1) ability to use standard html editors for app design 2) no separate download of XML/JSON/JS/other app UI templates 3) easier integration with current web server frameworks, which already work with html, (like JSF or wicket) they would not need to generate qx's proprietary xml format or something else, just plain html tags with qx's attributes mixed in. 4) no need to learn yet another XML dialect I imagine it wouldn't be so hard to adapt qxBuilder to read page's html. Plus it could demand pages to be XHTML compliant in order to make parsing simpler/easier/faster too. What do you think? -- ------------------------------ Zenrique Steckelberg
<<winmail.dat>>
