Hello Sebastian, sounds good to me - I also think that additional computing load must be avoided at all costs - Derrell and I have been talking about it here:
http://bugzilla.qooxdoo.org/show_bug.cgi?id=422 I have implemented a custom event routing mechanism which forwards specific events to the server if their name matches a filter, but this solution is restricted to DataEvents - to include any other event such as mouse or resize events would slow things down. I am open to any solution such as an event router and will be happy to discard my own custom solution if something like this can make it into the trunk. I think the event system is powerful and can be used as a general message bus for non-time-critical business logic. Instead of objects calling each others' methods, objects issue messages with data which are then picked up by other objects for handling. Christian > I don't like the solution to be integrated in qx.core.Target. I would > like it better to add specific events to a special event router which > then informs registered objects about any of these events. This is a > lot cleaner than exclude tables and a deep integration in > core.Target. The overhead of many events would be to dramatic. I can > imagine of something like a widget monitor which reacts on all > widgets relevant stuff and for example a IO monitor which monitors > all IO related things. > > What do you think? > > Sebastian > > > > Am 16.05.2007 um 16:02 schrieb Christian Boulanger: > >> Hello, >> >> qooxdoo's event system is really neat. There is one thing that I was >> thinking about: it would be good if one could "hook into" the >> events being >> dispatched without explicitly having to attach event listeners. >> I want to propagate certain events to the server without the event >> dispatcher or event listener knowing about it. Since I want the >> ability to >> filter by event type, I need to know about *all* events that take >> place >> regardless of source or target. One way this could be implemented >> is to >> place the call in the event dispacher code to an empty hook function >> which then can be defined if needed. >> >> Would this be consistent with qooxdoo architecture? I could write a >> small >> patch to implement this. >> >> Best, >> >> Christian >> >> >> ---------------------------------------------------------------------- >> --- >> This SF.net email is sponsored by DB2 Express >> Download DB2 Express C - the FREE version of DB2 express and take >> control of your XML. No limits. Just data. Click to get it now. >> http://sourceforge.net/powerbar/db2/ >> _______________________________________________ >> qooxdoo-devel mailing list >> [email protected] >> https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
