hi,
Christian Boulanger wrote:
No, but seriously, there is a huge advantage for using XML:
- you can avoid verbose, semantically redundant, and error-prone
javascript coding ("Verbose" seems to be my favorite word lately ;-) )
well, i was involved in a xul project. as time goes by, the xml code
contained redundant parts, contained errors and so on. imho your points
are not specific to JS, they occur with any language or description
language.
if the xml is really descriptive it is an advantage. but this is an
ideal world i've never seen :-)
- you can deliver on-the-fly compressed javascript to the client of your
own code (not only of the qooxdoo core files)
hm, apache2 can do this too (filter), tomcat can do this (afaik with
filter), cherrypy (with filter). i guess php can do this too out of the box.
- you can easily exchange GUI templates
in theory. did you ever try to "easily exchange templates" in a
HTML-webapp or a xul-app?
it's not fun and really not easy :-)
- you could even, if you want, create converters from other GUI XML
description languages (such as XUL or Qt) or at least, rewrite those
with less hassle
sorry, but i don't believe :-). it is extremely hard to map different
gui frameworks. most of the time you have a small subset of all as a result.
- you can structure the XML to contain meta-information on the GUI
correct, but that has nothing to do where this xml is parsed (server <->
client).
- you can use the same XML code even if the API changes - all you need
to update is the parser
well this depends on your xml grammatic. if this is completely decoupled
from qooxdoo you are right. but then your parser will be a complete new
product with new widgets and new properties. you cannot borrow the
propertynames from qooxdoo ... they can change.
nevertheless: now my application is coupled to your xml-DTD or schema
:-). and if this changes ...
i think this is one reason for xul, because this is standarized. but
imho it will be real real real hard to map xul to qooxdoo. imho it is
not possible.
As to speed: Server-side parsing is fast ennough to be not noticeable,
especially compared to the performance of QxBuilder. It has been one
idea of Sebastian early on, by the way!
sure, serverside parsing is fast (if you don't have hundreds or
thousands of clients), but clientside parsing is not really slow :-).
in both cases qooxdoo objects have to be instanciated, properties have
to be set, and so one. one solution also has to parse xml on the client,
the other not.
but if you think serverside xml helps, no problem :-)
Christian
-------------------------------------------------------
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
