Agreed, this is not a case where you want inheritance. On Nov 19, 2011, at 9:49 AM, Chuck Hill wrote:
> > 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. A good link Chuck pointed to in an earlier discussion on this topic. http://objectdiscovery.com/solutions/publications/roles/index.html > > >> 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 > > > > > > > > _______________________________________________ > 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/ramseygurley%40gmail.com > > This email sent to [email protected]
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]
