On Nov 16, 2007, at 3:35 PM, Christopher Nebel wrote:
On Nov 16, 2007, at 8:00 AM, Christiaan Hofman wrote:
Then you shouldn't use it for your object specifier, as it does
not uniquely identify the object.
Well, maybe. You say it's unique, but not very unique? How unique
is it? [1] The Scripting Interface Guidelines (you have read them,
right?) have this to say about "id" properties:
I have read them, but I must admit I didn't memorize them :)
id
A value that uniquely identifies the object. IDs are never
localized and are typically not under the user’s control and
therefore are read-only. They should at least be unique within a
container – in most applications, they are unique within the
entire application – and must remain valid for at least the
lifetime of the application process or the object, whichever ends
first.
The type of value may be anything: common choices are an integer, a
UUID, or a bundle identifier. The type of value for any particular
class should always be the same.
In your case, the key bit is probably "unique within a container".
An "id" attribute doesn't have to be universally unique, it just
has to uniquely identify an item in that container. Having an "id"
attribute is useful, since it lets you say "order id x" instead of
"first order whose order number is x", which is doubly annoying
when you know there's going to be at most one match.
According to a strict adherence to the above, I shouldn't use it.
However, see below.
--Chris Nebel
AppleScript Engineering
[1] My old high school librarian maintained that questions like
that were nonsensical. Either something is unique or it isn't;
qualifiers on "unique" make about as much sense as qualifiers on
"pregnant".
Then I think your librarian never spent much time outside of the
pristine logic of the library :)
In my case, the order number (which although I say number, is better
represented as a string since it can have a letter after the number
part) is indeed unique within my company, even to the standards of
your librarian. No two orders will ever have the same number.
But in my application, I have to give newly-created orders
_something_ in this field, even if it's a blank. And the user does
have control over this field, although I could introduce some sanity
checking to force uniqueness if I wished.
However, I am in the happy situation of creating this application for
exactly one user whose use of the app is under my control, and I have
tested how it reacts with this "quasi-unique" order number as the ID
and it seems to do very well.
The worst case I can invent is when the user accidently creates a
duplicate ID and comes to me wondering why when he clicks on a button
in Filemaker, it takes him to the wrong order in my scheduling
application. At which time I will say "you made two orders with the
same number, dummy!" and all will be well. (I know this attitude
makes many developers nearly freak out with the shiver shakes but
trust me, until you have programmed for a very small set of users who
are "captive", you haven't lived. I'm sure this statement will come
back to haunt me some day...
But thank you for your response--things are looking very nice with
the properties of my app and the single application suite command I
have implemented and now I'm banging my head on my first object-based
command which is not working at all. I swear I always have trouble
until the first time I get something working. You might hear back
from me on Monday I fear. _______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-implementors mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/applescript-implementors/email@hidden
