Re: Inheritance...
Re: Inheritance...
- Subject: Re: Inheritance...
- From: Florijan Stamenkovic <email@hidden>
- Date: Fri, 9 May 2008 10:08:21 -0400
I dealt with this issue by adding the following code in my abstract
root... It avoids the pitfall you mention. One must be careful
however that *every* subclass implements _getType() because the
compiler will not complain as long as any of the super-classes have
this.
public void awakeFromInsertion(...){
super...
setType(_getType());
}
public abstract Integer _getType();
I've also been thinking about what you say below, adding
awakeFromInsertion(...) both on the client and the server, and that
makes no sense to me. I mean, I only insert EOs on the client, which
then get transferred to the server. In what kind of a setup did you
experience this weirdness?
Flor
On May 09, 2008, at 07:39, David Avendasora wrote:
Oh, and I almost forgot, if you have multiple levels of
inheritance, your awakeFromInsertion setting the class type is a
little more tricky because the first thing you do in
awakeFromInsertion is to call super.awakeFromInsertion. The problem
is that if the class you are working on is more than one
inheritance level away from the abstract parent, you have to check
to see if super.awakeFromInsertion already set the type and then
override it.
So that if statement should look like this:
if (type() == null || type() == 1 {
setType(2);
}
Dave
On May 8, 2008, at 12:00 PM, David Avendasora wrote:
Oh, and BTW if this is Java Client you need to set the restricting
qualifier (or type) on both the client AND the server, AND
surround the setter with a check for null first, otherwise it
causes all sorts of weird unrelated errors when you try to delete
an instance of the subclass. This drove me nuts for over a year
with Undo Manager errors.
For example:
if (type() == null) {
setType(2);
}
It will work fine to insert new instances without the "if" clause,
but it will bite you when you delete. As soon as I added the if
clause to my code my deletion errors went away instantly.
Dave
On May 8, 2008, at 11:38 AM, Florijan Stamenkovic wrote:
On May 08, 2008, at 11:27, Mike Schrag wrote:
All that matters is that you have some restricting qualifier
that specifies how to differentiate the two entities (the value
doesn't matter, but you do need some attribute that specifies
which one is a SubEntity1 and which one is a SubEntity2). If
you use Wonder, I recommend turning on
er.extensions.ERXEnterpriseObject.applyRestrictingQualifierOnInsert
=true . If you don't, you will also need to set the value of
your restricting qualifier in your awakeFromInsertion so new
objects of your entity type get assigned properly (meaning, if
you have a type = 2 restricting qualifier, you need to setType
(2) in awakeFromInsertion). applyRestrictingQualifierOnInsert
in Wonder will automagically look at your restricting qualifier
and figure out what to set for you, so it's just one less thing
to mess up.
I did get that... Apple's docs explain it clearly... What I don't
get is why they use the integers 2 and 9 in a three entity setup
(abstract root + 2 concrete) as qualifier values... The way they
put it, it seems like it is important for some reason. Well,
apparently it isn't...
Tried to look this up on the web, but that part of the
documentation isn't there anymore... I have it in pdf, the
"UsingEOModeler" thingy...
F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40avendasora.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40avendasora.com
This email sent to email@hidden
_______________________________________________
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