hi,
one silly question: what's the problem which should be solved by this
"xul->qooxdoo" converter?
i fear you will end up in a converter which maps a subset of xul to a
subset of qooxdoo. so neither the xul guys are happy nor the qooxdoo
guys. it will be ok for simple form-based-apps, but i'm really in doubt
if you want to use QxTree, QxListView and much more of the complex
widgets (QxWindow, QxBarView, QxColorSelector, ...)
but back to my first question, i thought you want qooxdoo applications
to start quicker. hm, i don't see how a xml->qooxdoo converter which
runs on the serverside can help.
ok, you can try to load only those qooxdoo parts which are needed. but:
you have to "understand" the qooxdoo class hierarchy. well imho, the
easies and efficient way is to load "qooxdoo.js" (in its compressed form).
sorry, but i really don't see the advantage of a serverside component
which parses XML and produces (qooxdoo specific) JS.
sorry and thx
</usc>
Christian Boulanger wrote:
ChristophDorn schrieb:
I think the main value of using XUL is to borrow from a standard that
has
many UI-related challenges solved using standard patters as Ben
mentioned.
There are also a host of tools starting to spring up to edit XUL
definitions. Even visual drag and drop tools to design UI's.
Ok, I agree on this. Being able to use GUI builders would be great.
Using the QxBuilder syntax will work, but it may get pretty verbose
when you
start to link many components together with events.
But here comes the problem: with your XUL2QX parser, you need to map all
the attributes of XUL to those of Qx and still after that, the
javascript working with the widgets doesn't correspond to the XUL model.
Isn't that a major drawback?
quickly. There would be a client javascript component to it as well that
will call event callbacks with a context more comprehensive than qooxdoo
currently provides with its event system.
I assume this is where you would have to map all events, methods and
properties. This seems to me to be a HUGE task! I would be delighted to
be able to re-use my XUL knowledge, but still I am a bit worried that we
are taking on a huge task and might end up creating a hybrid that
neither takes advantage of the low-level qualities of Qx nor can deliver
on the promises of XUL. But I will be happy to be convinced by a
proof-of-concept.
Why don't we proceed like this: You implement a proof-of-concept parser
based on XUL, and I will, if time permits (I have a completely different
job) try to write a simple Serverside QxBuilder converter, based on the
client side code. In the final server product, these converters can be
plugged-in at will.
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
