In that case, the difference between Broadcast and eventsForNamedDispatch
is implementation? Some time ago I filed a bug to optimize
BroadcastEverywhere by introspecting all the on*Event methods at block
initialization (or at rendering, or something like that), and creating an
events listener table. I guess this is actually the mechanism used by
NamedDispatch...
oops, I thought I put john or donn on the cc, looks like i completely
forgot ...
https://bugzilla.osafoundation.org/show_bug.cgi?id=3607
brendan
On Tue, 02 Aug 2005 14:03:47 -0700, Donn Denman <[EMAIL PROTECTED]>
wrote:
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
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
