On 18 Nov 2007, at 2:48 AM, Christopher Nebel wrote:
On Nov 16, 2007, at 2:03 PM, Paul Bruneau wrote:
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...
Then I'd say that your order number meets all the criteria of an
"id" property. (Notice that it said they're *typically* not under
user control; that's not a requirement.) If there's a requirement
that they be unique, then that's plenty unique for "id"'s purposes,
even if the requirement isn't enforced in code. (Though, as M.
Juran points out, it would be useful if it were.)
--Chris Nebel
AppleScript Engineering
But I think it makes sense to make it read-only. Otherwise something
like this would break:
set anOrder to order id "12345"
set id of anOrder to "67890"
because anOrder still refers to 'order id "12345"', which does not
even exist anymore (note that anOrder is an object specifier, not a
cocoa object).
That would mean that the id (order number) can only be supplied in
AppleScript at creation time (or, of course, to find it). You can
create a new order then as follows:
make new order with properties {id:"12345"} at end of orders
You can find the id by examining [NSScriptCommand currentCommand] in
your -init method.
