Cocoa Application Architecture - Think More About AppleEvents and OSA?
Cocoa Application Architecture - Think More About AppleEvents and OSA?
- Subject: Cocoa Application Architecture - Think More About AppleEvents and OSA?
- From: Simon Liu <email@hidden>
- Date: Thu, 30 Sep 2004 10:13:27 +0100
Hi,
I have read in Matt Neuberg's AppleScript book that BBEdit's design is
based around AppleEvents, that target-action methods end up sending
AppleEvent's to itself to process. I also found this quote via
google:
"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
- 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
? 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?
---
Simon Liu
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden