[Dev] Menu items support named dispatch

Brendan O'Connor brendano at osafoundation.org
Tue Aug 2 14:14:33 PDT 2005


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 <donn at osafoundation.org>  
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/


More information about the Dev mailing list