On Sep 27, 2006, at 1:49 PM, Zak Burke wrote:
Tarun Reddy wrote on 9/27/06 4:18 PM:
I assume that awakeFromInsertion (based on the name) does not execute
until the actual insertion of the object in the database, which means
I
can't rely on the value until the object has been saved. I am
currently
using the method to store creation date info, but I was hoping to get
an
initial value in before being saved to the database.
(Trying to generalize the EditIdea form for both existing objects that
I'm editing, and newly created objects. Since the status field is
effectively a selector of sorts, I would like to have it always
populated, even before being saved to the database, for business logic
checks.)
This has been an interesting sort-of Best Practices thread to follow.
I dunno if this is good or bad, but I always use static constructors
for
my EOs and I just do initialization there. I have code in my
EOEditingContext subclass that sets date-created and date-updated
fields
in saveChanges(). This keeps the EO constructors clean but still lets
me
set default values. For example:
public static SomeEO(EOEditingContext ec)
{
SomeEO eo = new SomeEO();
eo.insertObject(eo);
eo.setDefaultString("foo");
// ...
return eo;
}
The first two lines could be replaced by createAndInsertInstance().
This
is just the pattern I fell into before I knew about that method.
I've evolved from doing using awakeFromInsertion() to (frequently)
using a variant of the above that I find more useful. Implement static
creation/initialization methods in, e.g., Person, such as
public static Person newPersonWithEmployer( ec, employer ) {
return newPersonWithEmployerAndCreationDate( ec, employer, new
NSTimestamp() );
}
public static Person newPersonWithEmployerAndCreationDate( ec,
employer, creationDate ) {
Person person = new Person();
ec.insertObject(person);
person.setCreationDate(creationDate);
person.addObjectToBothSidesOfRelationshipWithKey(employer,
"employer");
/* any additional initialization code goes here */
return person;
}
Advantages:
1. I have a habit of overlooking what happens in awakeFromInsertion()
until I find myself debugging something. With this it's usually clear
what's going on just by looking at the calling code.
2. I've forgotten to include super() in awakeFromInsertion() too many
times, no similar issue here.
3. This approach provides a simple, clear way to support multiple
initializers (unlike awakeFromInsertion()).
4. The method(s) can be shared throughout the program and eliminate the
problem of inadvertantly doing slightly different initializations in
different places.
5. Also because of sharing, it's easier to update initialization code
as the EO changes. Update one file in one framework, no search
required.
I always include the ec as an argument but you could, in a case like
this, get it from the employer.
Tom
_______________________________________________
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]
