Re: Basic question - lightweight to-one relationship from entity to POJO/enum
On Apr 15, 2010, at 4: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 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) {
This is where enums are great IMHO. Instead of if(){} else if(){}
else if(){} stuff scattered throughout your various classes, you can
just use something like
eo.reflexPlantarRight().calc();
Then you'd have an enum like
public enum ReflexPlantar {
EXTENSOR() {
public void calc() { ... }
},
WHATEVER() {
public void calc() { ... }
};
public abstract void calc();
}
That way, you're just using polymorphism. If you need to add a new
enum type, you don't have to go to all the different classes that
touch it to add new if/else branches. You just implement the abstract
methods for the enum and you're done! (^_^)
With enumeration entities, you're pretty much stuck with that sort of
procedural branch logic on some unique identifier in the entity. It's
really easy to forget to add another if/else somewhere. Forgetting to
implement an abstract method on an enum though results in a compiler
error. Enums are just more elegant to me.
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 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
ent
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
You may want to check out the WireHose Framework, in general, and
com.wirehose.base.WHEOCache, in particular... Regards, André
On 2010-04-15, at 4: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 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 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:/
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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 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"),
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
There are a few reasons I can think of to put lookup tables in the database:
1) Can edit the user-viewable text without recompiling (if you design your
lookup tables correctly)
2) Localization
but most importantly:
3) Sorting happens at the database
sacha
On Apr 15, 2010, at 2:00 PM, Mike Schrag wrote:
> i'm an enum fan ... lookup tables are dead to me, because, as someone already
> pointed out, you almost always want them synced between code and the
> database, which invariably creates a mismatch at some point. the only reason
> i use lookup tables at this point is if the enumerated values are
> runtime-mutable. technically putting the enum name in a field isn't
> unnormalized, either, since that IS the "primary key" for the enum. just
> because it happens to be a string isn't a problem.
>
> ms
>
> On Apr 15, 2010, at 4: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 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 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 en
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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 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-
d...@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/m
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
i'm an enum fan ... lookup tables are dead to me, because, as someone already
pointed out, you almost always want them synced between code and the database,
which invariably creates a mismatch at some point. the only reason i use lookup
tables at this point is if the enumerated values are runtime-mutable.
technically putting the enum name in a field isn't unnormalized, either, since
that IS the "primary key" for the enum. just because it happens to be a string
isn't a problem.
ms
On Apr 15, 2010, at 4: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 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 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
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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 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 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
--
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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 (^_^)
At least that's what I hear in my head whenever I think about it.
cue: Chuck.
So far, I have not been using enums - though I can see the
attraction. The big reason for that is that I am stuck with a tool
that can only parse Java 1.4 syntax. Using something like
ERXEnterpriseObjectCache with these Lookup EOs eliminates the fetching
problem leaving you with a small memory and performance overhead. It
is not something that keeps me up at night.
Chuck
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/archive%40mail-archive.com
This email sent to arch...@mai
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
On Apr 15, 2010, at 8:53 AM, Ramsey Lee Gurley wrote: > Wait, what is the DBA doing with some dumb DB tools when he has D2JC? (^_~) Ahg! Touché. ( ! ) That's a "vertical" smiley, btw. Dave ___ 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
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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 (^_^)
>
> 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
>>
>
smime.p7s
Description: S/MIME cryptographic signature
___
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
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
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..."
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
On Apr 14, 2010, at 6:07 PM, David Avendasora wrote:
> I've always just created Entities for these types of things so all
> relationships work the same.
For me, it depends on the usage. If it is something like a transaction state
(e.g. ACCEPT, DECLINE, ERROR) I would go with an enum. In a case like that, the
enum value is going to determine program logic. In other words, I'm not going
to add a new state to the database (REVIEW for instance) and then have the app
magically know what to do with it. I know there are cases where an enumeration
entity makes sense, but for me, those are synonymous with a shared editing
context. If it is possible, I avoid them.
Besides, enums are pretty nifty! (^_^) I like them. I can use them in switches,
they make great singletons, and they can work like operators... pretty neat
stuff.
> Is there substantial savings to doing things this way over simply having EOs?
>
> Dave
Well, there's only going to be one of each enum in memory. So, that's a bonus.
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. Does
any of that make a big difference? I don't know. Can't hurt though (^_^)
Ramsey
>
> 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
smime.p7s
Description: S/MIME cryptographic signature
___
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
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
I've always just created Entities for these types of things so all
relationships work the same.
Is there substantial savings to doing things this way over simply having EOs?
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
Ramsey: thank you! I was battling the wrong binding (possibleChoices
rather than restrictedChoiceKey) and have successfully updated my
project's EOgenerator templates as per the objectstyle wiki.
Thank you again - I owe you more than one beer if you ever come to the
UK!
Mark
--
Dr. Mark Wardle
Specialist registrar, Neurology
(Sent from my mobile)
On 9 Apr 2010, at 01:18, Ramsey Lee Gurley wrote:
On Apr 8, 2010, at 5:08 PM, Mark Wardle wrote:
Ramsey: thanks for this.
More thought on this I should frame this as two questions: how
to
adequately model a property as a java enum and how to use such a
property via conventional and D2w components.
The former isn't clear cut AFAIK. In particular, I've been bitten by
the bug (?) highlighted in this email:
http://lists.apple.com/archives/webobjects-dev/2009/Nov/msg00380.html
I only came across this when I managed to find out that I would need
to use com.eldrix.MyClass$MyEnum rather than the dot notation.
Well, you can either update templates or you can make the Enum free
standing in its own java file rather than nesting it inside another
class. That's what I would probably do personally, but updating
templates shouldn't be all that difficult either. I just prefer to
keep them separate.
Am I missing done documentation on this or do I need to update the
template file as suggested in that email?
For the second issue, I see ERD2WEditToOneRelationship will handle
this although I haven't quite got the hang on the possibleChoices
binding and in particular trying to use the enum's own values getter.
All hints gratefully received!
Ok, so, you model an enum attribute, then set your componentName
like you normally would
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
componentName = ERD2WEditToOneRelationship [Assignment]
Now all you need to do is provide a keypath that gives the list of
allowable enums.
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
restrictedChoiceKey = "object.visualScoreChoices" [Assignment]
Which means you'll need to create a method on your FormEdssFull
object like
public NSArray visualScoreChoices() {
//TODO Based on your object state, return what possible choices
are available. This just returns everything.
return new NSArray(VisualAcuity.values());
}
And then for the display string in the popup, bind your
keyWhenRelationship
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
keyWhenRelationship = "toString" [Assignment]
That will give you choices like
NORMAL
SIGNS_ONLY
MODERATE
MARKED
Unless you set localizeDisplayKeys of course!
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
localizeDisplayKeys = "true" [BooleanAssignment]
At which point you can return localized display strings by putting
them into your Localizable.strings file like
"NORMAL" = "Normal";
"SIGNS_ONLY" = "Signes Seulement";
"MODERATE" = "Moderate";
"MARKED" = "Marqué";
Pardon the French if it is incorrect. Translation provided by babel
fish (^_^) Anyway, I think that should work for you. Standard
warnings apply: Completely untested code, your milage may vary,
objects in mirror are closer than they appear ... (^_^)
Ramsey
On Thursday, April 8, 2010, Ramsey Lee Gurley
wrote:
For an enum specifically, you can use a custom component like
https://r2d2w.svn.sourceforge.net/svnroot/r2d2w/trunk/ERR2d2w/Components/Nonlocalized.lproj/R2D2WEditEnum.wo/
Or you can just use rules and the ERDEditToOneRelationship
component. That component is flexible enough to handle the job.
Spoiler: I actually plan on covering exactly this example in
detail at WOWODC this year (^_^)
Ramsey
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/rgurley%40mac.com
This email sent to rgur...@mac
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
On Apr 8, 2010, at 5:08 PM, Mark Wardle wrote:
> Ramsey: thanks for this.
>
> More thought on this I should frame this as two questions: how to
> adequately model a property as a java enum and how to use such a
> property via conventional and D2w components.
>
> The former isn't clear cut AFAIK. In particular, I've been bitten by
> the bug (?) highlighted in this email:
> http://lists.apple.com/archives/webobjects-dev/2009/Nov/msg00380.html
>
> I only came across this when I managed to find out that I would need
> to use com.eldrix.MyClass$MyEnum rather than the dot notation.
Well, you can either update templates or you can make the Enum free standing in
its own java file rather than nesting it inside another class. That's what I
would probably do personally, but updating templates shouldn't be all that
difficult either. I just prefer to keep them separate.
>
> Am I missing done documentation on this or do I need to update the
> template file as suggested in that email?
>
> For the second issue, I see ERD2WEditToOneRelationship will handle
> this although I haven't quite got the hang on the possibleChoices
> binding and in particular trying to use the enum's own values getter.
>
> All hints gratefully received!
Ok, so, you model an enum attribute, then set your componentName like you
normally would
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
componentName = ERD2WEditToOneRelationship [Assignment]
Now all you need to do is provide a keypath that gives the list of allowable
enums.
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
restrictedChoiceKey = "object.visualScoreChoices" [Assignment]
Which means you'll need to create a method on your FormEdssFull object like
public NSArray visualScoreChoices() {
//TODO Based on your object state, return what possible choices are
available. This just returns everything.
return new NSArray(VisualAcuity.values());
}
And then for the display string in the popup, bind your keyWhenRelationship
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
keyWhenRelationship = "toString" [Assignment]
That will give you choices like
NORMAL
SIGNS_ONLY
MODERATE
MARKED
Unless you set localizeDisplayKeys of course!
100: entity.name = 'FormEdssFull' and propertyKey = 'visualScore' =>
localizeDisplayKeys = "true" [BooleanAssignment]
At which point you can return localized display strings by putting them into
your Localizable.strings file like
"NORMAL" = "Normal";
"SIGNS_ONLY" = "Signes Seulement";
"MODERATE" = "Moderate";
"MARKED" = "Marqué";
Pardon the French if it is incorrect. Translation provided by babel fish (^_^)
Anyway, I think that should work for you. Standard warnings apply: Completely
untested code, your milage may vary, objects in mirror are closer than they
appear ... (^_^)
Ramsey
>
>
>
> On Thursday, April 8, 2010, Ramsey Lee Gurley wrote:
>> For an enum specifically, you can use a custom component like
>>
>> https://r2d2w.svn.sourceforge.net/svnroot/r2d2w/trunk/ERR2d2w/Components/Nonlocalized.lproj/R2D2WEditEnum.wo/
>>
>> Or you can just use rules and the ERDEditToOneRelationship component. That
>> component is flexible enough to handle the job. Spoiler: I actually plan on
>> covering exactly this example in detail at WOWODC this year (^_^)
>>
>> Ramsey
>>
>> 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/rgurley%40mac.com
>>>
>>> This email sent to rgur...@mac.com
>>
>>
>
> --
> Dr. Mark Wardle
> Specialist registrar, Neurology
> Cardiff, UK
smime.p7s
Description: S/MIME cryptographic signature
___
Do no
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
Ramsey: thanks for this.
More thought on this I should frame this as two questions: how to
adequately model a property as a java enum and how to use such a
property via conventional and D2w components.
The former isn't clear cut AFAIK. In particular, I've been bitten by
the bug (?) highlighted in this email:
http://lists.apple.com/archives/webobjects-dev/2009/Nov/msg00380.html
I only came across this when I managed to find out that I would need
to use com.eldrix.MyClass$MyEnum rather than the dot notation.
Am I missing done documentation on this or do I need to update the
template file as suggested in that email?
For the second issue, I see ERD2WEditToOneRelationship will handle
this although I haven't quite got the hang on the possibleChoices
binding and in particular trying to use the enum's own values getter.
All hints gratefully received!
On Thursday, April 8, 2010, Ramsey Lee Gurley wrote:
> For an enum specifically, you can use a custom component like
>
> https://r2d2w.svn.sourceforge.net/svnroot/r2d2w/trunk/ERR2d2w/Components/Nonlocalized.lproj/R2D2WEditEnum.wo/
>
> Or you can just use rules and the ERDEditToOneRelationship component. That
> component is flexible enough to handle the job. Spoiler: I actually plan on
> covering exactly this example in detail at WOWODC this year (^_^)
>
> Ramsey
>
> 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/rgurley%40mac.com
>>
>> This email sent to rgur...@mac.com
>
>
--
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Basic question - lightweight to-one relationship from entity to POJO/enum
For an enum specifically, you can use a custom component like
https://r2d2w.svn.sourceforge.net/svnroot/r2d2w/trunk/ERR2d2w/Components/Nonlocalized.lproj/R2D2WEditEnum.wo/
Or you can just use rules and the ERDEditToOneRelationship component. That
component is flexible enough to handle the job. Spoiler: I actually plan on
covering exactly this example in detail at WOWODC this year (^_^)
Ramsey
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/rgurley%40mac.com
>
> This email sent to rgur...@mac.com
smime.p7s
Description: S/MIME cryptographic signature
___
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
