Christoph Dorn schrieb: > 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.
Nice idea, but how is this related to XML? XML is just a format, which also isn't really easy to handle using javascript. > 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.) You don't really want to move this communication logic out of javascript? I think we should first think about a solution using pure javascript without using any *QxBuilder or backend driven system. > > 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. Could you describe how does this exactly work? With some examples? > > 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. Yes, sure. But to solve this in PHP is not what I like. I find it much clearer to have this system directly in javascript. This would maybe mean to develop some registry and message bus. Sebastian > > 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, > > 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] > <mailto:[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/ > <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]> > [mailto:[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 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642> > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > <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 > <http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642> > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > <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] <mailto:[EMAIL PROTECTED]> > Browse: www.unfold.co.nz <http://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 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
