Re: Inheritance...
Re: Inheritance...
- Subject: Re: Inheritance...
- From: Florijan Stamenkovic <email@hidden>
- Date: Fri, 09 May 2008 11:49:16 -0400
Something that does it all in one place (root of the hierarchy)...
Should take care of the problem with intermediate classes. It also
fails quickly, as a reminder if one adds new subclasses to the
hierarchy, but forgets to deal with their type identifiers.
private static final Map<String, Integer> mdSubtypes =
new HashMap<String, Integer>();
static{
mdSubtypes.put(Asset.ENTITY_NAME, 2);
mdSubtypes.put(BankAccount.ENTITY_NAME, 4); // subclass of Asset
mdSubtypes.put(Cash.ENTITY_NAME, 3); // subclass of Asset
mdSubtypes.put(Expense.ENTITY_NAME, 1);
}
public void awakeFromInsertion(EOEditingContext ec){
super.awakeFromInsertion(ec);
// set the MD type
Integer mdType = mdSubtypes.get(entityName());
if(mdType == null) throw new IllegalStateException(
"IDs not provided for subentity: "+entityName());
setMdType(mdType);
}
I'm still concerned that you aren't checking it to see if it is
null before setting it... According to the Apple documentation:
http://developer.apple.com/documentation/WebObjects/
Enterprise_Objects/BusinessLogic/chapter_4_section_3.html
"Determining if the attribute is null is not usually necessary
except in three-tier Java Client applications."
Interesting, I never saw that... As for checking on null, sorry,
forgot to mention that JBND does that for me (or, to be more precise,
checks if the value being set is equal to the value currently had,
for attributes, and if so, it ignores the setting call)
:P
Now, they don't explain why it's important for JC, but I _think_
the client-side EditingContext acts something like a nested EC to
the server EC, so when you copy the client-side EC back to the
server, the EO is getting "inserted" again into the server-side EC,
and _I believe_ awakeFromInsertion gets called on the server again.
If you've already set the value of the attribute on the client (and
not necessarily to
what awakeFromInsertion will set) then when it shows up on the
server, it gets overridden by the server-side awakeFromInsertion.
Yuck.
Yuck, and urgh.... Sounds fishy though, we need to verify this. I
will check it out.
As far as the weirdness goes, other than values getting overridden
unintentionally, the problems that I ran into were errors with the
Undo Manager any time I tried to delete an instance of a class that
had awakeFromInsertion called without first checking if the value
was null.
<feelingVeryGood> I don't do NSUndoManager </feelingVeryGood>
I consider it a JC best-practice to always have the
awakeFromInsertion methods match on the client and server...
Well, this applies if you are doing server-side work. I try to avoid
that. However in principle I agree with the philosophy. It's just a
pain to maintain.
Any new instances that were created on the server will then be
copied down to the client, and _I think_ get awakeFromInsertion
called on them again.
No, this does not happen. Once an EO is saved, I awakeFromInsertion
doesn't get called on it when fetched to the client. I am not sure
about the scenario you mention above, but of this I am. Actually, I
think that once an EO is saved, awakeFromInsertion never gets called
on it again, anywhere.
Now, If I had a common class that both the Server and Client
classes extended I'd put it there so I wouldn't have duplicate
code, but until Mike gets off his lazy butt and finishes adding
support for a common parent class to EntityModeler and Veogen I
have to put the same awakeFromInsertion call on both sides. ;-)
I am worried about integrating JBND with this. Since all JBND used
EOs need to implement the DataObject interface. The easiest way is to
make them inherit EOFDataObject, but this is client side only class,
meaning: bye-bye common EO code. I need to figure out a way to solve
this.
F
_______________________________________________
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