| EOF can handle it. Sure. But users can’t handle the Primary Key! [Jack Nicholson face] Expose it, and they’ll want to change it. Guaranteed.
Besides, just displaying it is no reason to expose it. You can display it just by using ERXGenericRecord’s primaryKey() method. You can fetch by PK too, ERXEOControlUtilites.objectWithPrimaryKeyValue or ERXEOGlobalIDUtils.fetchObjectsWithGlobalIDs. Plus, once you expose it, you have to populate it yourself. That is a headache all on its own.
On Feb 28, 2014, at 2:48 PM, Chuck Hill < email@hidden> wrote:
Actually, exposing the PK is fine with EOF. Exposing an FK is what causes real problems.
On 2014-02-28, 1:47 PM, "Aaron Rosenzweig" wrote:
Hi Ted,
If you must expose the primary key… make a duplicate attribute with a Read format and make it read only.
Look at page 41 of this document:
Exposing the PK as a class property could mess with the way EOF assigns the PK and it opens it up to possibly being modified.
On Feb 28, 2014, at 4:41 PM, Jesse Tayler < email@hidden> wrote:
generate a unique ID, if you don’t mind using HEX….
On Feb 28, 2014, at 4:32 PM, Chuck Hill < email@hidden> wrote:
Does it mean anything to the user? I assume it does, otherwise, why would you show it? So what is going to happen when they see this:
id number description client
3456 Blue Dress Amex
Where is 3458? Because that IS going to happen if you use the PK.
Chuck
On 2014-02-28, 1:25 PM, "Theodore Petrosky" wrote:
I need to create an Entity that will have a user visible id number. I thought I would just use the primaryKey but I recall reading so many times don't use the primaryKey for this.
This is a very simple Entity. It has a description, a Client, and a boolean (isActive). When the user views a list of these Entities, he/she will see:
id number description client
3456 Blue Dress Amex
when I insert a new Entity, I only need to supply the description and Client (from a popup). WO will supply the ID number. So why not use the primaryKey here? The user can never edit it. and none of these Entities will ever be deleted.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Help/Unsubscribe/Update your Subscription:
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|