Bugzilla – Full Text Bug Listing
| Summary: | Registering a service that produces events is a pain | ||
|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | Simon Kaegi <simon_kaegi> |
| Component: | Client | Assignee: | Simon Kaegi <simon_kaegi> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ken_walker, mamacdon |
| Version: | 0.2 | ||
| Target Milestone: | 1.0 M2 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
The ServiceRegistration shenanigans are no more. If your service supports event you should use orion/EventTarget internally and expose addEventListener, and removeEventListener. The ServiceRegistry no longer does this for you automagically although it will handle the communication aspects if you plugin registers a service that exposes addEventListener and removeEventListener. |
Looking at how we're registering in-page services we're doing stuff like: new mFavorites.Favorites({parent: "favoriteProgress", serviceRegistry: serviceRegistry}); we instead should be doing: serviceRegistry.register(new mFavorites.Favorites({parent: "favoriteProgress"}); -- The problem I think is that tying into the event api is a real pain. In particular you don't get access to the registrations eventTarget until after the service is registered. We need to make this easier by maybe using registering/unregistering calls on the service implementation to pass it what it needs or something similar.