Re: EO/Java class default Values
Re: EO/Java class default Values
- Subject: Re: EO/Java class default Values
- From: shaun <email@hidden>
- Date: Wed, 04 Oct 2006 22:32:21 +0930
Hi,
I've just caught the tail end of this thread so I apologise in advance
if I am repeating something already mentioned.
Tom M. Blenko wrote:
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
No, Insertion into the editing context.
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.
That shouldn't be a problem.
(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
while I agree this is a good approach, I think that the point of using
awakeFromInsertion is to provide "defaults" and IMO, should be used to
do so whereever possible. It does provide a CLEAR indication of the
must-have values for a given object in one easy to recongnize central place.
You can still provide factory methods as you have descibed above to add
relationships as required and for other things you might want to do,
but the defaults are provided by the implementation of
awakeFromInsertion. eg)
public static Person newEmployee(ec, employer){
Person p = newPerson(ec);
p.addObjectToBothsides..(employer,"employer");
return p;
}
public static Person newUnEmployedPerson(ec){
Person p = newPerson(ec);
//whatever needs doing here... I dunno..
return p;
}
protected static newPerson(ec){
Person p = new Person();
ec.insertObject(p);
return p;
}
public void awakeFromInsertion(ec){
//status options are "I" or "A"(Inactive or Active).
setStatus("A");
//a creation date for reporting.
setCreationDate(new NSTimestamp());
}
creationDate is set in awakeFromInsertion as a default, in one spot. If
you want to specify a different creation date, then simply call
setCreationDate again on your returned Person where appropriate.
This has the benefit of ensuring that defaults ARE set. If another
developer comes along and adds a new factory method, or just does a
createAndInsertInstance(..) they KNOW that the object will be
constructed with sensible defaults. They dont have to know which method
of the N overridden methods they need to call to get an initialised
Person object - all newly inserted Person objects will be automatically
initialised!
Sometimes when you have a lot of overridden methods code can become a
bit harder to grok at a glance.
When a developer knows where to look for defaults(awakeFromInsertion) i
think that it makes life a lot easier, rather than skimming through a
bunch of long method names to see a default value or to understand which
values need/should have defaults and what those defaults can be.
FWIW. I also like to use the factory method pattern for constructing
WOComponents too. YMMV. It seems that quite often something which makes
sense to one person doesnt work so well for another, just something to
consider I guess..
regards,
- shaun
_______________________________________________
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