The XML representation that qx.client.Builder can eat supports event
listeners.
=>
Yes, but apparantly qx.client.QxBuilder is quite slow in generating the application
based on the xml. Especially for large applications. Also, having a server
implementation of qx.client.QxBuilder (XML definitions could be similar to what
qx.client.QxBuilder
uses) would allow for validation of the XML based on extensive meta data as
well as automatically generating documentation for the
application.
Whether in XML or _javascript_, there is no magic way of determining
automatically what to connect where.
A nice shortcut when attaching to several widgets might be something like
my_function.listensTo([
{ my_widget: ["my event type"] },
{ my_text_input: ["click", "focus", "my event type"] }
])
(with a corresponding XML representation) but you still need to decide where what when.
A nice shortcut when attaching to several widgets might be something like
my_function.listensTo([
{ my_widget: ["my event type"] },
{ my_text_input: ["click", "focus", "my event type"] }
])
(with a corresponding XML representation) but you still need to decide where what when.
=>
You are correct. That is what is needed to handle user and other
events. You can code that in _javascript_ or XML.
When
using XML you can however do something like:
<OX:Field id="field1" observes="fieldgroup1"/>
<OX:Field id="field2"
observes="fieldgroup1"/>
Where
each field observes the "fieldgroup1" broadcaster. The broadcaster could be
implemented to update the field values, enable or disable input on the UI etc...
There can be standard and custom broadcasters.
Or
something like:
<QX:Table id="table1"/>
<OX:Field id="field1">
<observes element="table1" listen="OnSelectionChange"
/>
</OXField>
(Similar to XUL: http://xulplanet.com/tutorials/xultu/broadob.html)
This
becomes very powerful when we have exact XML definitions for each QxWidget to
define what data it can load. This allows data to move between widgets and from
the server to the widgets in generic format without having to code any
_javascript_.
You
can of course code all this with _javascript_ and abstract it to a level where it
can do the same with helper functions, but if you already go to that effort why
not define it in XML?
I
think we are using the wrong term for this now. It is not an event system as
such, it is an application framework to build standard applications that hooks
extensively into the event system.
Christoph
All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
