On 6. May. 2009, at 11:04 , Theodore Petrosky wrote:
1. I am inexperienced
Aren't we all? Just depends on the topic ...
2. I feel that I work in a Vacuum and being inexperienced I think I
am heading to perdition (or at least feeling alone)
3. At times I hesitate to ask because the answers are sometime over
my head...
Shouldn't be a problem. Explanations can be rephrased and you'll learn.
4. as for the naming..... I need to learn a lot.... and this project
has morphed from a simple contact manager to a lot more.
As a general rule, I try to name instances (the real things that are
of a specific type (which is definted by the Class)) according to what
they actually are:
Contact => contact or myContact or theContact or currentContact,
depending on the context
EOEditingContext (or ERXEC) => editingContext
and so on. I avoid short variables like ec or s (for session) or c
(for contact) as they can be confusing and make the code harder to
read, but I also avoid too long names like:
theContactThatWasCreatedJustForTheFunOfIt. Impossible to read ...
Nevertheless, classes, methods and variables should always have
descriptive names so that the name tells you what it is and maybe what
it is used for.
BTW what would you have called the contactEO?
editingContext or contactEditingContext
John's answer below is the exception.... I still don't understand
WHY this works, but at least I can continue and hopefully learn a
little.
Because EOF populates the fields that are used for relations only, if
they are not a class property. If they are a class property you are
basically telling EOF that this field is under YOUR (the programmers)
control and not under EOF's.
cug
_______________________________________________
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]
