I think its a great idea. Not everyone uses qooxdoo for their whole
application. It would be great to have qooxdoo replace html components if
and where applicable/supported. It makes it much easier to migrate
traditional HTML applications to qooxdoo in a hybrid approach.

A solid qooxdoo/ajax framework for attaching events (to widgets that then
call the server) and parsing server responses will be needed to make this
work seamlessly. This will be built with the php/qooxdoo framework we are
considering.

Christoph


-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Zenrique
Steckelberg
Sent: Tuesday, April 11, 2006 2:13 PM
To: [email protected]
Subject: Re: [qooxdoo-devel] QxBuilder + Server-side integration ideas


Jim, the change I proposed is not really a change but some additional
feature, which by the way already exists in similar form in qx's qxBuilder
function.

Another point is that there are component web frameworks like the ones I
cited (JSF and wicket) which could leverage on qooxdoo's features and create
a best of both worlds solution (a great javascript framework on the client
side and a great component web framework on the server side). Plus, some
people would rather avoid javascript coding if the can, so for one example,
wicket framework makes it possible to create a complete AJAX app without
ever touching one line of javascript, just by using its components which can
encapsulate JS code completely, as each wicket component would use QX's
functions under the hood automagically. Having this html templating could
make this kind of integrated solution much easier with qx.

This is just my suggestion/opinion.

------------------------------
Zenrique Steckelberg


Jim Hunter wrote:
> 
> 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
>>
> 
> 

--
View this message in context:
http://www.nabble.com/QxBuilder-%2B-Server-side-integration-ideas-t1433940.h
tml#a3869610
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



-------------------------------------------------------
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

Reply via email to