Hi all,
I dunno if this qualifies as a best practice, but for every ivar I
create in WOBuilder with the "Add Key..." contextual menu item, I start
the name with an underscore and check the generate source code for
getter/setter. WOBuilder automatically creates the getter and setter
without the underscore, and the ivar is protected and begins with an
underscore (I'm still on WO 5.2.3).
Another pain in the head for stateless manually synchronized reusable
components is remembering to include new ivars in reset(), so some time
back I created some functionality in a generic subclass for resuable
components that automatically performs reset to null on any protected
ivars beginning with an underscore. this complements creation of ivars
beginning with underscore having setters/getters. It works really well
and avoids the problems associated with forgetting to include newly
created ivars in a reset method specific to every reusable WOCompent.
It is also efficent in that the list of ivars that require resetting is
created once only for each reusable WOComponent class.
The ugly details are here....
http://homepage.mac.com/kelleherk/iblog/C1133025376/E1146937278/
index.html
Great discussion, thanks, regards,
Kieran
PS. Chuck, when is the new book scheduled for amazon.com .... or even
PDF purchase and download?!
On Feb 9, 2006, at 6:01 PM, Chuck Hill wrote:
Hi Art,
On Feb 9, 2006, at 2:44 PM, Art Isbell wrote:
On Feb 9, 2006, at 12:33 PM, Jerry W. Walker wrote:
Like Chuck, I tend to use straight assignment for many of the same
reasons. However, in this example I just didn't want to make
arbitrary decisions on whether the members whose values I was
setting were iVars or methods.
Does it bother anyone else that WOBuilder generates protected rather
than private ivars so that WO can access these ivars directly rather
than using accessor methods? Seems like a bad practice to me.
Are they protected or public? I thought there were public in recent
versions. But, yeah, it bothers me sometimes.
Instead, I make all my ivars private forcing WO to access them via
accessor methods unless there's a good reason to make these ivars
accessible to subclasses (but then they should probably use accessor
methods also).
I'm not too overly strict in this area. If it is a binding (say item
in a repetition) that I will never access in code, then I don't see
the harm in making it public. Also, if it is a page (rather than a
component that might get reused), I am a little less paranoid about
public ivars that I don't (much) use in code. For anything that might
get subclassed and reused, or which is used in code, I make the ivar
private and add accessor methods.
Chuck
-- Coming in 2006 - an introduction to web applications using
WebObjects and Xcode http://www.global-village.net/wointro
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 ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/
kieran_lists%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
