Just to add another one to the mix, I use CSV text files in Resources for
static lookups. two columns, first is key, second is value.
They are lazy-initialized into a immutable dictionary and used in Popup menus,
etc.
A few static utility methods and you are done. Usually values are either
strings or Integers. So two different utility methods handle the appropriate
type. The advantage is that this business logic stuff is kept with the app, and
is easy to maintain and edit in development. I am not religious about this. I
just use it when it suits me. Other times I use db tables, other times, enums.
YMMV.
Kieran
On Apr 15, 2010, at 5:08 PM, Chuck Hill wrote:
>
> On Apr 15, 2010, at 1:52 PM, Mark Wardle wrote:
>
>> I've found this interesting.
>>
>> My problem is I already have >80 entities. For instance, I have an entity
>> representing structured medical data: as such it has about fifty pick lists
>> - representing these as separate entities will be a nightmare! Using enums
>> seems to work well and keeps these items in a private namespace.
>
> I'd not be keen on 80 lookup tables either.
>
>
>>
>> I also find it very convenient to create a NSDictionary with keys and
>> default values that can be used in awakeFromInsertion - Ive found it a bit
>> clumsy to start doing fetches to set default values in awakeFromInsertion.
>>
>> Unless there's a WO-way of doing that.....
>>
>> The other issue is when calculating things.
>>
>> Using an enum, I can do:
>>
>> If (reflexPlantarRight == ReflexPlantar.EXTENSOR) { ....
>>
>> I've always found checking EO identity a bit clumsy!
>>
>> Mark
>>
>> --
>> Dr. Mark Wardle
>> Specialist registrar, Neurology
>> (Sent from my mobile)
>>
>>
>> On 15 Apr 2010, at 18:53, Chuck Hill <ch...@global-village.net> wrote:
>>
>>>
>>> On Apr 15, 2010, at 5:53 AM, Ramsey Lee Gurley wrote:
>>>
>>>>
>>>> On Apr 15, 2010, at 8:07 AM, David Avendasora wrote:
>>>>
>>>>>
>>>>> On Apr 14, 2010, at 9:49 PM, Ramsey Lee Gurley wrote:
>>>>>
>>>>>>
>>>>>> Well, there's only going to be one of each enum in memory. So, that's a
>>>>>> bonus.
>>>>>
>>>>> Memory is cheap. :-)
>>>>>
>>>>>> They are fast to access... I don't block a thread waiting on a fault.
>>>>>> That's good too. On that same line of thought, there's no need to
>>>>>> prefetch them.
>>>>>
>>>>> Well, reading in 5 key-value rows from a table can't take all that long,
>>>>> even if you don't prefetch them. Obviously if they are used thousands of
>>>>> times in a transaction, then you'll need to speed it up, but I'd optimize
>>>>> it only if it's actually slowing things down.
>>>>>
>>>>>> Does any of that make a big difference? I don't know. Can't hurt though
>>>>>> (^_^)
>>>>>
>>>>> Depends on your definition of pain., I guess. :-)
>>>>>
>>>>> I've always looked at it as a case of if the value is defined only in
>>>>> code, how do people who are reading the data directly out of the DB know
>>>>> what the value in the DB means? How do you make everything consistent
>>>>> between your app and a reporting system reading data out of it?
>>>>>
>>>>> DBA: "Oh hey, this transaction has a status of 1. What does 1 mean? Is it
>>>>> Active? Is it Closed? What? Now I've got to track down that bleeping
>>>>> developer and ask him to interpret this data. Would it have been so hard
>>>>> for him to just include all the context of his application in the DB
>>>>> where anyone can get at it? It's not like a few 5-row key-value tables
>>>>> are going to bring the DB to it's knees..."
>>>>
>>>>
>>>> Wait, what is the DBA doing with some dumb DB tools when he has D2JC? (^_~)
>>>>
>>>> I believe the enum prototype in wonder stores them as a string. So,
>>>> continuing with Mark's example, your DBA would just see NORMAL,
>>>> SIGNS_ONLY, MODERATE, etc. He doesn't see some fk and need to jump to
>>>> another table to figure out what that fk happens to be. It sounds like
>>>> you're arguing against enumeration entities now (^_^)
>>>
>>> But said DBA will then commence whining about non-normalized data.
>>>
>>>
>>>>
>>>>>
>>>>> At least that's what I hear in my head whenever I think about it.
>>>>>
>>>>> cue: Chuck.
>>>>>
>>>>> Dave
>>>>>
>>>>>
>>>>>>>
>>>>>>> On Apr 8, 2010, at 4:52 AM, Mark Wardle wrote:
>>>>>>>
>>>>>>>> Hi all, please forgive a very simple question but I'd like to create a
>>>>>>>> lightweight (non-EO) to-one relationship from an EO. I make heavy use
>>>>>>>> of D2W so I want to fulfil the WO/EOF rules and use to-one
>>>>>>>> relationship components....
>>>>>>>>
>>>>>>>> I usually create a new entity and have a genuine heavyweight EOF
>>>>>>>> relationship but I have several properties for which this seems
>>>>>>>> excessive.
>>>>>>>>
>>>>>>>> I have an entity (FormEdssFull) which can have a visual field score
>>>>>>>> for both right and left eye.
>>>>>>>>
>>>>>>>> Can I do this with a java enum?
>>>>>>>>
>>>>>>>> public enum VisualAcuity {
>>>>>>>> NORMAL(0, "Normal"),
>>>>>>>> SIGNS_ONLY(1, "Signs only:"),
>>>>>>>> MODERATE(2, "Moderate"),
>>>>>>>> MARKED(3, "Marked");
>>>>>>>>
>>>>>>>> /* insert enum constructor etc... */
>>>>>>>> }
>>>>>>>>
>>>>>>>> and then create the appropriate accessor and mutator in the entity?
>>>>>>>>
>>>>>>>> What do other people do in these situations?
>>>>>>>>
>>>>>>>> Many thanks,
>>>>>>>>
>>>>>>>> Mark
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dr. Mark Wardle
>>>>>>>> Specialist registrar, Neurology
>>>>>>>> Cardiff, UK
>>>>>>>> _______________________________________________
>>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com
>>>>>>>>
>>>>>>>> This email sent to webobje...@avendasora.com
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Do not post admin requests to the list. They will be ignored.
>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>>> http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40mac.com
>>>>>>>
>>>>>>> This email sent to rgur...@mac.com
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Do not post admin requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>>> Help/Unsubscribe/Update your Subscription:
>>>> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
>>>>
>>>> This email sent to ch...@global-village.net
>>>
>>> --
>>> Chuck Hill Senior Consultant / VP Development
>>>
>>> Practical WebObjects - for developers who want to increase their overall
>>> knowledge of WebObjects or who are trying to solve specific problems.
>>> http://www.global-village.net/products/practical_webobjects
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> http://lists.apple.com/mailman/options/webobjects-dev/mark%40wardle.org
>>>
>>> This email sent to m...@wardle.org
>>>
>
> --
> Chuck Hill Senior Consultant / VP Development
>
> Practical WebObjects - for developers who want to increase their overall
> knowledge of WebObjects or who are trying to solve specific problems.
> http://www.global-village.net/products/practical_webobjects
>
>
>
>
>
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/kieran_lists%40mac.com
>
> This email sent to kieran_li...@mac.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
