Ok, john straightened me out on IRC... for those of you following the
thread:
eventsForNamedDispatch (or eventsForNamedLookup as it may be called
soon) is NOT an event dispatching mechanism like I previously thought.
It is a way for an event to get registered with CPIA, so that it can be
looked up by name and dispatched. The way I'm thinking about it is
this: there are lots of "Event" items in the repository, but not all of
them are "registered" with CPIA. This "registration" allows us to
lookup events by name usually from Python code such as from CPIAScript.
The registration happens by a block declaring "these are the events I'd
like to register" - some of the confusion seems to be about which block
actually declares this list. It could be an event dispatcher like a
menuitem, or an event receiver, such as the calendar view. In any case
lets call this the owning block, whether or not the block technically
"owns" the event or not.
The registration happens when the owning block is rendered, and
unregistered when the owning block is unrendered. This prevents events
from being registered if their owning block isn't visible in the UI..
(and there is also some debate as to whether this is actually valuble
or not.
But the thing to remember is that the only purpose for this
registration is to be able to look up the events by name, which is why
they are important to CPIAScript.
Alec
Alec Flett wrote:
I guess what I'm getting at is this:
1) if you broadcast events, blocks that have defined onXXXEvent will
receive the message - i.e. a developer has gone out and written the
method because they want to receive the message.
2) if you dispatch events by name, blocks that register for the event
via eventsForNamedDispatch will receive the message (via an onXXXEvent
method of course) - i.e. a developer has gone out and written the
method, and registered for the event name, because they want to receive
the method
My point is that while the implementation under the hood may be
different, the effect is the same - the developer who wants to receive
the call does a little work - and the caller doesn't know who its
sending the message to.
Personally, I would be in favor of ditching BroadcastEverywhere
entirely (and probably also BroadcastWithinEventBoundary) and use the
named-event registration, since you can accomplish the same thing more
efficiently with eventsForNamedDispatch.
Alec
John Anderson wrote:
eventsForNamedDispatch are a list of events for a block. When this
block is rendered, these events are added to the list of events that
you can dispatch by name. When the block is unrendered, the events are
removed the from the list of events that can be dispatched by name. So
it controls which events you can dispatch by name. All events, whether
refered to directly via a reference or looked up by name are dispatched
the same way. Dispatching by name is just another way to find an event
which is dispatched like all other event.
All events go to onXXXEvent methods.
Broadcast describes how the event is dispatched, e.g. the event is sent
to more than one block
Dispatch-by-name events typically don't go to blocks who have
eventsForNamedDispatch
John
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
|
