Re: Primary keys, direct actions, and the WO "way"
Re: Primary keys, direct actions, and the WO "way"
- Subject: Re: Primary keys, direct actions, and the WO "way"
- From: Ray Kiddy <email@hidden>
- Date: Wed, 14 Jul 2004 11:38:42 -0700
On Jul 13, 2004, at 7:49 AM, David LeBer wrote:
On 13-Jul-04, at 10:29 AM, Amorya North wrote:
[Newbie alert!]
OK, I'm designing a site that'll have people's short stories on. The
stories are sorted into genres, so you'll be able to get a listing of
all the scifi stories, or all the fantasy stories, etc.
I'd like the lists of stories to be bookmarkable, so I understand you
need a direct action for that. As I understand direct actions, it
means you can't use the usual helpful WO stuff like passing objects
between pages. Everything has to go through the URL. Right?
Now, when developing in PHP, I would have just shoved the primary key
to the genre in question in the URL. Like
mypage.com/viewstories.php?genre=7.
But in everything I've read about WO, it says "don't touch the
primary key"!
It is not so much "don't touch the primary key" but more: treat the PK
as a database artifact and don't use it to store a value with meaning.
You can always get at an EO's PK using:
//assuming an EOEditingContext ec,
// and an EOEnterpriseObject eo, with a pk indentified as myPK
NSDictionary dict = EOUtilities. primaryKeyForObject(ec, eo);
Integer primaryKey = dict.valueForKey("myPK");
Or you can give each of your genre's a genre code of your own creation
and use that in your direct action.
David is correct here. This is the valid way to get the pk.
The original observation is also correct, though. The primary key does
not really work as an object level guaranteer of uniqueness. This is a
bit of an architectural issue which is papered over by the EOUtilities
methods. I have argued that the "primary key", as such, should not be
at all visible above the EOAccess layer, and any thing which requires
it to be visible in the EOControl layer is a bug. I tend to take purist
positions, though.
In my apps, I often will have a primary key that I do not want to show
the user under any circumstance and another attribute which I can set
which is derived from the primary key in a non-obvious way. This allows
me to hand the user something they can use to uniquely identify an
object, but I can restrict that access later without affecting the
actual database.
- ray
So how would I identify the genre in question in a direct action?
(Forgive me for not being entirely sure how direct actions work. If
It's entirely possible I've missed something major.)
;david
--
David LeBer
Codebase Software Systems
site: http://www.codebase.ca
blog: http://david.codebase.ca
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.