Kent Olsson schrieb:
Hej!
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)
it is a restriction in several ways.
* Sometimes you need to move nodes around
I would say unfortunately.
* You must render inside already visible areas (which dramatically
reduces the performance)
very slow
* qooxdoo's intention is not to generate interfaces defined in HTML.
keep it there...
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.
Not unusable, but performance-wise difficult to manage. Performance is
always relative to each user's previous experience.
Yes, but I think if you have ever seen a "normal" qooxdoo application,
you really don't want to use a QxBuilder based one anymore.
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.
XUL is well established, XAML too but I guess XUL will have a more
narrow applicability because of design issues. Will it ever be fully
accepted? That might be one of the reasons for the growth of
JavaScript!!! JavaScript is not at all the optimal language, but what
else is there which is widely accepted?
It's not only javascript in this case, but also CSS. JavaScript has some
limitations, but after some weeks I think the most programmers gets the
basics done quite quickly.
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.
What is more intuitive than something you have learned before?
OK. I agree. But these property lists inside attributes are even
uncommon for HTML (OK, the style attribute use something like this, too,
but it isn't used widely I think). Also it looks really complicated in
my opinion.
Sebastian, we have different backgrounds, way of thinking and the way we
do things. This is the never ending problem with all standards. When the
model becomes so flexible that the definitions can be overcome the
interest and usage of the technology will increase pretty fast.
Yes, this is true. But bad things don't get better just because many
people use them. ;)
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.
I agree.
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.
Modularity is the best choice. Scale every small unit down to its
smallest and absolutely most necessary parts, then many problems will be
ruled out.
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?
Initial invisible parts created fill up space and take time to transfer
and process. It also increases the overhead. Even better to be dynamic
as you mention...
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.
XHTML is maybe the most accepted and the most compatible model so far.
Parsing is not always so simple, but probably from a performance
perspective a useful way to go. The way to go!
Compatible? With what... do you mean the browsers? Sure - in this case.
But qooxdoo has many stuff which couldn't be modeled with simple HTML.
Why use something like HTML, if the most stuff isn't as great as in
qooxdoo. If you use HTML this means you insert all properties of an
object in a few attributes. These attributes must be different from the
HTML ones. The content of the attributes is more complicated, it's not
that easy to structure it in a good way and so on. HTML used in this way
is not really HTML. It just consists of some lines of DIVS with
attributes. Not really a good reason to use HTML as markup for qooxdoo
controls.
In my opinion the way to go is an own XML format which could handle all
the properties of qooxdoo in normal XML attributes. We could derive
parts from XUL, XAML or any other XML format which seems to be usable.
We could learn from the errors of others and try to make our one more
useful. Also it's no problem afterwards to try to convert any other XML
format like XUL to qooxdoo's markup. In my opinion a native qooxdoo
markup is the best choice (to repeat myself again).
Sebastian
Kent
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
-------------------------------------------------------
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
