Re: Updating EOObjects
Re: Updating EOObjects
- Subject: Re: Updating EOObjects
- From: LD <email@hidden>
- Date: Fri, 19 Aug 2005 13:25:13 +1000
Hi there,
On 19/08/2005, at 12:17 PM, Arturo Pérez wrote:
On Aug 18, 2005, at 9:41 PM, LD wrote:
On 19/08/2005, at 11:15 AM, Arturo Pérez wrote:
The other big thing is to follow a style of doing most of your
work in the appendToResponse() and to never mutate any on-page
data through the key values that WOBuilder can see.
I sense that appendToResponse has more important duties at hand...
Yes, probably, but for a newbie sticking with appendToResponse()
will get you started.
For newbies I reckon sticking with 'common' OO/Java practice helps
their comprehension. i.e., nothing new to learn assuming they know
how to program already ;-)
but all kinds of things go wrong with the keys that WOBuilder
accesses (which most consider getters/setters).
Such as? I've never had problems with key-value pairs in my
components when I've followed the basic practice of keeping the logic
for how Objects are created/updated to get/Set. That way - NO OTHER
code needs to worry about it. takeValuesFromRequest simply utilises
NSKeyValueCoding's takeValueForKey on the component. I can't see any
reason why manipulating your objects by overriding takeValues would
make any difference.
Now, what about validation etc...
One runs into problems if the getters/setters mutate their values,
especially if they are used as conditionals. One way to avoid this
to do save those mutating things for the appendToResponse(),
takeValues() and invokeAction phases of the RR.
What kinds of problems?
Isn't WOKeyValueConditional designed for such use...
Besides, haven't you heard that getters and setters are evil :-)
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Not that I care particularly but, without Eclipse's generate
getters&setters thing it's a pain.
The article seems to be arguing against the unnecessary use of public
getters/setters. i.e., think about the black box...
with regards,
--
LD
_______________________________________________
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