I am not looking at re-implementing the event system that
qooxdoo already has.
Rather my goal is to allow event handlers to be attached to
the UI based on XML definitions.
There are many standard events in a user interface that
need to be handled.
Say you want to run some code when a specific command is
triggered in the UI. The command may be triggered by a button or a list
selection or a tab change etc... Rather than writing code to attach the event
handler to each component manually (requiring you to keep track of references
etc...) the idea is that you link the event handler code to the UI components
via an XML definition where the underlying implementation knows exactly how to
listen for the event and how to call your code.
This should work for QX applications generated using our
PHPQxBuilder as well as applications coded by hand or generated by other systems
(as long as there is an interface that knows how to attach the listeners when
the application initializes.)
This is very similar to how XUL works. It takes care of all
the dirty work of disabeling buttons, triggering observers etc... with minimal
code.
The idea is to move away form requiring the developer to
keep track of object references, object hirarchies and other _javascript_
structures and rather work with named object ID's to obtain and trigger
events. With the PHPQxBuilder the application _javascript_ code can be generated
in the most optimal fashion which would be impossible to maintain by hand
allowing for best performance and allows the developer to focus on the business
rules of the application.
Sorry if this did not come across in my previous
wording.
Christoph
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Danny
Adair
Sent: June 21, 2006 5:03 PM
To: [EMAIL PROTECTED]; qooxdoo Development
Subject: Re: [qooxdoo-devel] Global event system
Hello,Sent: June 21, 2006 5:03 PM
To: [EMAIL PROTECTED]; qooxdoo Development
Subject: Re: [qooxdoo-devel] Global event system
Could you (maybe both) clarify this a bit?
qooxdoo _is_ event-driven http://old.qooxdoo.org/documentation/event-system
No matter what it is that happens, it will have been kicked off by an event (startup,mouse,keyboard,timer,transport...).
Christian, could you give a couple of examples of methods you are converting?
If let's say you ask the server for some data to populate a list view (using a QxRequest) - which again might have been fired by a mouse click on a button - your event listener for "completed" populates the list. If you want to update a completely different object at the same time - in your "old" approach the event listener would simply grab that (global or registered) object and change it. In your new approach, the event listener for "completed" would simply dispatch another event to which others (incl. the object itself) can react. Or: You just update the list view in the "completed" event, and have another event listener for changes to the list view.
Imo, how you want to cut this up, and whether this delegation makes sense or not depends on the design of your application.
Think about it this way: You _could_ dispatch an event for everything.
This increased flexibility - traded for the introduction of an additional layer - might not be needed everywhere.
Yes, instead of just adding a new tabview page, you could globally shout "I need a new tab view page" and then have the tab view react to that. Would you want to do that? Maybe.
I would say both ways can happily coexist.
Your also creating lots of events on the same (global) level that probably don't have anything to do with each other.
I don't know if this is already possible but it would be nice if an object could listen to events of a specifed type fired by (any of) its (grand) children.
Kind regards,
Danny
On 6/22/06, Christoph
Dorn <[EMAIL PROTECTED]>
wrote:
A global or uniform event system like this is essential for larger
applications to allow for flexibility and maintenance.
Most java applications make extensive use of listeners and event
dispatchers.
The performance of the model depends on how it is implemented and can be
very fast.
XUL provides a good guide as to how such a system may be implemented for
user interfaces. It covers all essential requirements and several differents
ways to tie into the event system.
A good intorduction to XUL can be found here:
http://xulplanet.com/tutorials/xultu/
Extending the model to the server is trivial once the client supports it.
This will be a major part of the PHP QXBuilder I am working on.
It would be great if you restructure your application as you described as we
can then use it with minor modifications to test the event system that will
be part of the builder.
Christoph
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Christian
Boulanger
Sent: June 21, 2006 2:24 PM
To: qooxdoo Development
Subject: [qooxdoo-devel] Global event system
Hi,
I am currently converting my app away from using objects which call each
other's methods to for some behaviour to objects which communicate which
each other through global events
(window.application.createDispatchEvent("foo"),
window.application.createDispatchDataEvent("foo", {blub:true},
window.application.addEventListener("foo", function(e){....}), and am
very much intrigued by the idea. Advantages include that I do not have
to give objects names in the global namespace or in an object registry.
All objects just exist independently and listen for each others events
to react to them (or not). All the behaviour code is located at the
object level - it is also easier to keep the application stable because
missing or broken functions cannot break it. I am thinking of extending
the system to include client-server communication.
Since the idea seems so nice to me, I wonder what the drawbacks might
be. Do you expect a major performance loss?
Thanks for any input,
Christian
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
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
--
Danny W. Adair
Director
Unfold Limited
New Zealand
Talk: +64 4 472 1679
Fax: +64 4 472 1680
Write: [EMAIL PROTECTED]
Browse: www.unfold.co.nz
Visit/Post: 22a Clifton Terrace, Kelburn 6005, Wellington, New Zealand
==============================
Caution
The contents of this email and any attachments contain information which is CONFIDENTIAL and may be subject to LEGAL PRIVILEGE. If you are not the intended recipient, you must not read, use, distribute, copy or retain this email or its attachments. If you have received this email in error, please notify us immediately by return email or collect telephone call and delete this email. Thank you. We do not accept any responsibility for any changes made to this email or any attachment after transmission from us.
==============================
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
