Hi Jose,
Jose Henrique Steckelberg F. schrieb:
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?
There are several issues with this type:
* To reuse existing dom-nodes is only possible for really simple widgets
(even in dojo)
* Sometimes you need to move nodes around
* You must render inside already visible areas (which dramatically
reduces the performance)
* qooxdoo's intention is not to generate interfaces defined in HTML.
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.
I think QxBuilder is nice, but unusable for large applications. I think
a server-side transformation would be the better choice here.
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>
Looks something like dojo ;)
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
Not really. The layout features have couldn't be modeled with simple
HTML. qooxdoo has many more features than realizable with "simple" HTML.
As qooxdoo is more a application than a page design toolkit, I think the
best choice is to model some XML dialect like XUL or XAML.
Even if you use HTML you are the most of the time restricted to the
attributes you have defined somewhere in your additional DTD. It's just
not as intuitive to write qxWidget="qxTree"
qxSetup="width:200,height:400", ... or where ever you want to define the
additional properties for your widgets.
2) no separate download of XML/JSON/JS/other app UI templates
In my opinion this could also be an advantage, because the browser is
able to cache this stuff.
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.
I think real application frameworks which could provide application
parts for single requests are the better choice. Especially for large
applications with many dialogs and sub-windows.
4) no need to learn yet another XML dialect
Also what's about updates? How do you like to open a window which other
content for example. How to realize dynamic interfaces? How to define
initially invisible parts?
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.
Just my 2 cents.
Sebastian
What do you think?
--
------------------------------
Zenrique Steckelberg
-------------------------------------------------------
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
