Bug 177647 - Provide a mechanism to contribute new event types
Summary: Provide a mechanism to contribute new event types
Status: VERIFIED FIXED
Alias: None
Product: EMF Services
Classification: Modeling
Component: Validation (show other bugs)
Version: unspecified   Edit
Hardware: PC Linux
: P2 enhancement
Target Milestone: ---   Edit
Assignee: David Cummings CLA
QA Contact:
URL:
Whiteboard:
Keywords: api, contributed
Depends on:
Blocks:
 
Reported: 2007-03-15 16:13 EDT by Christian Damus CLA
Modified: 2017-02-24 15:08 EST (History)
0 users

See Also:


Attachments
Proposed patch (41.81 KB, patch)
2007-03-20 14:22 EDT, David Cummings CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Damus CLA 2007-03-15 16:13:33 EDT
When live validation validates notifications, the event type of the notification is compared against a list of predefined types in EMFTEventTypes.  If the event type is not in EMFTEventTypes, the notification is not validated.

There are cases where clients wish to define their own event types for their own custom notifications.  An example might be "Add to container" and "Delete from container" events.  The client can derive these custom notifications from the raw EMF-defined notifications, and in doing so would make it easier to target containment changes without having to specify all possible containers (which could be many).
Comment 1 David Cummings CLA 2007-03-20 14:22:02 EDT
Created attachment 61436 [details]
Proposed patch
Comment 2 Christian Damus CLA 2007-03-21 17:08:21 EDT
Committed the patch, with a change to the proposed constraintProviders schema.  Reinstated the enumeration of core <event> element names and added a new <customEvent> element, similarly structured, whose name is required by not enumerated.  This clearly indicates the dependency on custom (non-EMF-defined) notifications types.
Comment 3 Nick Boldt CLA 2008-01-28 16:35:32 EST
Move to verified as per bug 206558.