Re: Address Book bugs
Re: Address Book bugs
- Subject: Re: Address Book bugs
- From: Bill Cheeseman <email@hidden>
- Date: Fri, 06 Sep 2002 15:14:19 -0400
on 02-09-06 1:15 PM, Paul Berkowitz at email@hidden wrote:
>
May I ask why Address Book couldn't have been a normal application
I wish I had the time to explore Address Book more, because it looks really
fascinating.
I have had time to read the developer documentation for Address Book's Cocoa
API, as well as the release notes, and there has been some discussion of the
Cocoa API on the Cocoa developer lists. This leads me to make a few
comments:
1. It's clear that the Address Book Cocoa (and Carbon) APIs are
first-generation. The release notes point out that the method to remove a
custom property, for example, is present but not operational. Also, I asked
why some awkward construct in the Cocoa API wasn't implemented in the usual
elegant Cocoa fashion, and the answer was that this feature "has been
requested;" i.e., the Address Book team has put it on their to-do list. So
you should expect lots of bugs, omissions, and awkwardnesses at this stage.
2. The whole concept of the Address Book is very funky. It's meant to be
easily extensible, using any of the APIs (Carbon, Cocoa, AppleScript). For
example, any developer can add properties (like "favorite color," or
whatever), and every ABPerson in the database suddenly has a favorite color
property. Furthermore, these custom properties can be single-value or
multiple-value properties (you could add a favorite colors [plural]
property, for example). Applications that don't know about favorite color or
favorite colors can still use the database, and they'll never notice that
some other application added these properties. This has led to some
implementation decisions that might otherwise have been made in a more
traditional way.
3. There are potential namespace conflicts in the way the Address Book is
set up. The Cocoa documentation suggests, for example, that developers who
add new properties should be sure to use unique names for them. But there's
no registry, so how well is that going to work? The documentation suggests
using domain names (a common concept in bundled applications in Mac OS X)
that include the name of the developer and the name of the implementing
application; if developers heed this advice, it may actually work.
4. The AppleScript dictionary seems to be more or less a one-to-one wrapper
for the Cocoa API. So lots of things probably have to be done on the
AppleScript side in unfamiliar ways. I suspect that a diligent AppleScripter
may find it easier to figure some of this out by reading the Cocoa
documentation. (I also suspect this is the wave of the future for
AppleScript, what with the Cocoa AppleScript APIs having their own way of
doing things.) Among other things, I have the impression that AppleScripters
have to take seriously the idea that Address Book is full of nested records
and/or lists.
5. The newly-revamped AppleScript Web site has a list of pages where new
AppleScript Jaguar technologies are discussed. Address Book is one of them.
Unfortunately, it doesn't link to anything yet. Hey, Sal, forget that
O'Reilly conference and get back to work!
I don't know whether this is of any help, but I hope so. Especially the part
addressed to Sal.... ;->
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
Croquet Club of Vermont -
http://members.valley.net/croquetvermont
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.