| Alec is right, eventsForNamedDispatch is really a registration mechanism for events, not a way that they are dispatched (we should change its name to make this clear). When you post an event it has various ways to dispatch to the handler(s) for that event. But before you can post any event you have to be able to locate it. The eventsForNamedDispatch registration allows you to simply post the event based on its name, without knowing its location. For example, we have a set of events that add items to the sidebar. These events are posted by parcels that want to be somewhat independent of the core of Chandler. Rather than having to lookup the event in some sidebar or global path, it locates the event using its name. Currently the AddToSidebar events are in a global list, but it's nice that the example parcels don't need to know that information.
- donn
On Aug 2, 2005, at 1:49 PM, Alec Flett wrote: (This is probably more a question for John)
I'm not sure I understand the use of eventsForNamedDispatch? this is something put on the target block that is to receive the event from the menu item? What dispatch type gets sent to blocks with eventsForNamedDispatch?
If that's the case, then it seems like we have (somewhat, not completely) redundant named events registration - at least it seems like:
a) "Broadcast" events go to blocks whose classes have onXXXEvent methods
b) "Dispatch-by-name" events go to blocks who have eventsForNamedDispatch set to the right event.
Aren't these effectively the same idea except for the mechanism used to actually find the target events (Broadcast walks the tree while I think the other method has some sort of registration mechanism?)
Alec
Donn Denman wrote: Summary
------------
If you ever create menu items for Chandler, you probably should have an attribute defined for "eventsForNamedDispatch" on your MenuItem, or it won't be accessible from CPIA Script.
Details
--------
In our dynamic user interface, where blocks come and go, it's handy to have a mechanism that sends an event to whichever block is available to handle that event. For this reason CPIA has had the ability to dispatch to events using the event's name. This is implemented as an attribute "eventsForNamedDispatch" on Block. Essentially, this allows the block to publish events that it, or its children blocks, can handle. This feature has not been widely used, until now.
CPIA Script is now leveraging off of CPIA's named event dispatch, picking up any events that have been published. So now there's a second reason to use "eventsForNamedDispatch" on blocks you create - they will be visible to CPIA Script. I have already updated all the blocks that define events, mostly Menu items and Toolbar items, to publish their events if appropriate. In the future, when you're creating menus, or blocks in general, consider if you want your event to be accessible to others, and from CPIA Script. If you don't want your menu to be scriptable, don't add the "eventsForNamedDispatch" attribute, and that will keep your event from being directly callable.
This information will go into the CPIA Author's Guide once we get a chance to write it.
- Donn Denman
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
