Re: Cocoa Application Architecture - Think More About AppleEvents and OSA?

FROM : Dustin Voss
DATE : Thu Sep 30 18:47:09 2004

On 30 Sep, 2004, at 2:13 AM, Simon Liu wrote:

> "A deeper use of the OSA is to "factor" the user interface elements of
> the application from its core functionality. The user interface
> elements do not directly call the subroutines that do the work of the
> application. Rather they send AppleEvents back to the application,
> which receives these events, and then dispatches them to the
> appropriate internal routines."
>
> I'd be interested in hearing any views on this, real-world
> experiences, and some pros and cons of this architecture.  Is it worth
> peeling back the Cocoa layer and think in terms of events?
>
> My initial thoughts are:
> + Will help scriptability of application.  Should greatly assist in
> writing .sdef files since the AppleEvents have already been designed
> + Will help in safe multi-threading as a single runloop can be set to
> process AppleEvents that invoke internal routines to mutate a data
> model


+ Helps in designing your object model. You have to think about things 
like where data lives and how it can be addressed.
+ Forces you to add an object model verification layer to ensure an 
Event is valid.

> - Harder to write code as have to build AppleEvents (Apple technotes
> provide examples) and passing data structures through AppleEvents
> seems rather painful.  For Cocoa programmers not used to Carbon, will
> mean extra study


- Cocoa doesn't do a good job of supporting directly-dispatched Apple 
Events. I have written a class, though: 
<http://homepage.mac.com/WebObjects/FileSharing.woa/wa/downloadFile?
user=d.j.v.&path=.Public/DirectDispatching.zip>

> ? NSNotification seems to do this already but at a higher level.
> However delivery of notifications is not guaranteed, wereas
> AppleEvents are.. or can they drop off incoming queues?


Apple Events can't drop off the queue. However, notifications do not 
allow for responses, while Apple Events do.

A more equivalent higher-level construct is Distributed Objects calls. 
One guy is working on a DO-AS equivalency layer (called DOSA, 
"Distributed Objects Scripting Architecture"), but I don't know far 
along he is.

Ringo wrote:

> We ended up
> putting some things behind a facade with the view and controller
> layers going through this facade. In the end, the scripting engine was
> just a second user of the model, next to the UI. Personally, I would
> do the same for an AppleScriptable application.


Yeah, this is a good way to handle things.