Who should use this API

  • If you are developing a WPF Application, this API is recommended.
  • If you like the use of abstraction platforms such as Object Relational Mapping (ie NHibernate), ADO.net, loose coupling etc.

Who should currently not use this API

While I would like everyone to use this API, currently the following usecases are not supported in using the event API's functionality. The following should not provide issue to the API however.
  • WinForms development. (Due to the lack of event bubbling it is highly unlikely that this will ever be supported).
  • ASP development. (eventually it would be good to support this. It would require a javascript translation or possibly the use of silverlight)
  • Users against experimental software (Unfortunately there is a substantial delay for some events to be parsed. This will be resolved as soon as possible. This issue only effects user events as it is processed in a thread separate to the main application)

Reasons to use this API

Extensibility

As an application grows in complexity the applications View layer in a Model View Presenter/Controller pattern will likely require change. Accessing the View by query rather than solid references means that code in the Controller/Presenter Layer will continue to work for changes in the View layer providing View elements use the same predefined tags (meta-data) that was decided apon as an interface.

Decoupling of UI

Querying a User Interface rather than using fixed references to objects allows the controller/presenter layer in a Model View Presenter design to be unaware of what is in the User Interface until a query is executed. This means that event rules can be made for components that may not even exist at compile time.

Future of Events

If we take a moment to observe the Nintendo Wii controller, it is easy to see how the developers were inclined to make a motion capture tool due to complex nature of moving a device that can potentially be rotated or moved in many directions potenitally in one motion. Their tool allows for developers to easily capture complex motions. These motions are then able to be handled. The use of complex inputs are also used in the Opera webbrowser which responds to mouse gestures. The Microsoft Surface also demonstrates the use of parrallel events in the form of a multi touch screen. Event Algebra can be used to translate all of those usecases to a single complex event. I believe that the .NET framework will require extention in this area in a future release.

Meta Data

Currently events operate at a machine level and we get primative events such as a mouse click; Even an event such as double click is reasonably low level. This seems to be an areas which we can strive for a higher level of abstraction/thinking. Initiatives such as the symantic web believe that meta data is the future of the web in that it allows for high level reasoning on the context or meaning of data. A Microsoft Example is that of the excellent support for wsdl's which supply metadata to potential consumers of a webservice Understanding context enables sharing of data in a way that it is going to be understood properly. This library allows use of the .NET tag property for UI Elements. That allows for querying of the UI to for example find all UI items associated with a printing context. Meta data could be implied by a complex event that is custom to a usecase, rather than an event such as click which is almost always going to be purely context based.

Centralizing Events

Traditionally GUI components that are created at runtime require the event handlers to be created after the object is initialized at runtime. This doesn't provide a central location to understand all events that are happening in your system. The API provided allows for a centralized list of events. As we use queries to verify the source of an event we are not restricted to the lifetime of any particular object. If no objects currently satsify a query raised by an event on the UI then the event doesn't occur.

Last edited Dec 11, 2007 at 11:23 PM by rhwilburn, version 7

Comments

No comments yet.