On 2011-11-19, at 8:30 AM, Theodore Petrosky wrote:

> i guess i don't see how in your example a contact could be both an employee 
> and a vendor and a media rep

They can't that is the point of inheritance.  A Dog can be a Mammal, but it 
can't be a Cat or a Rat (well Chihuahuas excepted).  This is not a valid use of 
inheritance.  EOF will not allow this.  Look at the Role pattern.


> it seems to me that to use a contactType column, limits the contact to one 
> and only one subclass

Yes, that is absolutely required.  This and only this is a correct use of 
inheritance:
http://en.wikipedia.org/wiki/Liskov_substitution_principle


> my method lets a contact belong to many different subclasses. I was 
> questioning if this approach was 'good' or was I boxing myself into a corner 
> that would bite me later. 

EOF is going to explode!


Chuck


> --- On Sat, 11/19/11, Paul Yu <[email protected]> wrote:
> 
>> From: Paul Yu <[email protected]>
>> Subject: Re: inheritance (EO Subclass) ?
>> To: "Theodore Petrosky" <[email protected]>
>> Cc: [email protected]
>> Date: Saturday, November 19, 2011, 9:42 AM
>> Ted
>> 
>> I'm no expert on inheritance, but typically the setup
>> should be 
>> 
>> Contact (Parent class) with a idContactType, marked as
>> Abstract
>> ContactType (1, Employee; 2, Vendor; 3, Media)
>> Employee (Parent = Contact, Qualifier idContactType = 1)
>> VendorContact (Parent = Contact, Qualifier idContactType =
>> 2)
>> MediaContact (Parent = Contact, Qualifier idContactType =
>> 3)
>> 
>> Then from your
>> Company EO your relationship would be to Employee EO.
>> 
>> Your fetches would be
>> 
>> vendors = VendorContact.fetchVendorContact(ed,
>> VendorContact.SOME_INTERESTING.eq(someValue), null);
>> 
>> The type qualifier would be taken care of for you...
>> 
>> Paul
>> On Nov 19, 2011, at 9:00 AM, Theodore Petrosky wrote:
>> 
>>> I am learning about subclassing EOs. 
>>> 
>>> I have an entity;   Contact
>>> 
>>> and three subclasses Employee, VendorContact,
>> MediaContact
>>> 
>>> the qualifiers are:  isEmployee (bool) 
>> isVendorContact (bool)  isMediaContact (bool)
>>> 
>>> ie:
>>> isEmployee <> 0
>>> isVendorContact <> 0
>>> isMediaContact <> 0
>>> 
>>> testbed=# select * from t_contact;
>>> c_first_name | c_last_name | id | c_is_vendor_contact | c_is_media_contact 
>>> | c_is_employee 
>>> --------------+-------------+----+---------------------+--------------------+---------------
>>> Ted          | Petrosky    |  1 | t    | t     | f
>>> Bill         | Simpson     |  2 | t    | t     | t    
>>> Harold       | Wall        |  3 | f    | t     | t
>>> 
>>> so I set up a test page simple with ordered lists
>> wrapped in WOReps
>>> 
>>> and queried the backend to populate the NSArrays:
>>> 
>>> theEC  = ERXEC.newEditingContext();
>>> 
>>> vendors = VendorContact.fetchVendorContacts(theEC,
>> VendorContact.IS_VENDOR_CONTACT.eq(true), null);
>>> employees =
>> CompanyEmployee.fetchCompanyEmployees(theEC,
>> CompanyEmployee.IS_EMPLOYEE.eq(true), null);
>>> mediaContacts = MediaContact.fetchMediaContacts(theEC,
>> MediaContact.IS_MEDIA_CONTACT.eq(true), null);
>>> 
>>> System.out.println("Media List " + mediaContacts);
>>> System.out.println("Employees List " + employees);
>>> System.out.println("Vendor List " + vendors);
>>> 
>>> After I ran my app it barfed at me:
>>> 
>>> Error:    
>> java.lang.IllegalArgumentException: While trying to set the
>> field "anEmployee" on an object of type
>> com.eltek.components.Main we expected a
>> com.eltek.model.CompanyEmployee but received a
>> com.eltek.model.VendorContact with a value of
>> <com.eltek.model.VendorContact pk:"1">. This often
>> happens if you forget to use a formatter. 
>>> 
>>> Now I understand that I can not fetch these entities
>> in a single EC as any contact could be a member of any or
>> all subclasses.
>>> 
>>> Did I miss something (a property maybe [since
>> everything is a property]) or must I use multiple ECs in
>> this case? Obviously, that was my solution, set up a
>> different EC for each subclass. Then all is well (but is
>> it?).
>>> 
>>> Ted
>>> 
>>> _______________________________________________
>>> 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/pyu%40mac.com
>>> 
>>> This email sent to [email protected]
>> 
>> 
> _______________________________________________
> 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/chill%40global-village.net
> 
> This email sent to [email protected]

-- 
Chuck Hill             Senior Consultant / VP Development

Practical WebObjects - for developers who want to increase their overall 
knowledge of WebObjects or who are trying to solve specific problems.    
http://www.global-village.net/products/practical_webobjects







Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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]

Reply via email to