Sorry brain fart (dealing with bronchitis) - I meant single table inheritance.  
But if an object can be both then I would go with Ramsey's method.

Aloha,
Mr. Johnny Miller
Web Development Manager
Kahalawai Media Company
Lahaina, HI 96761
tel: (808) 661-7962 | mobile: (808) 283-0791
website | e-mail        

On Aug 13, 2013, at 10:31 AM, Theodore Petrosky <tedp...@yahoo.com> wrote:

> I like this method of inheritance however, why did you choose vertical 
> inheritance? I did one vertical and one single table. I put a qualifier 
> userType='Vendor' on the table.
> 
> I think the only thing 'wrong' with inheritance is that I can not create a 
> User that is both a employee and a vendor. There are cases where we have 
> clients that are also vendors.
> 
> I was looking at the migration that I am creating and now I see.
> 
> with vertical inheritance, it is actually creating a table in the database 
> with a foreign key. this would allow me to add specific meta data to my 
> inherited entity, whereas the single table does not create this table 
> therefore I can segregate the different 'roles' but can not add a specific 
> piece of meta data. Such as a person has a SSN but a business has an EIN (in 
> the US).
> 
> but that still leaves me with the problem of modeling a Vendor that is a 
> Person not a business. Couldn't we find an easier way to model this stuff.
> 
> Ted
> 
> 
> 
> 
> On Aug 13, 2013, at 2:59 PM, Johnny Miller <jlmil...@kahalawai.com> wrote:
> 
>> Use vertical inheritance and then use entity.name='Vendor'?
>> 
>> Sent from my iPad
>> 
>> On Aug 13, 2013, at 8:19 AM, Theodore Petrosky <tedp...@yahoo.com> wrote:
>> 
>>> I have been playing with D2W and I may have boxed myself into a corner.
>>> 
>>> A User is of a type. a User can be a Vendor or a Client or a Worker. So I 
>>> thought that I would create an attribute 'userType' in User. I wanted  to 
>>> have a Vendor tab and a Client tab and I have it mostly working. 
>>> 
>>> when I create a ListVendorPage:
>>> 
>>> public WOComponent listVendorAction() {
>>>       
>>>       EOEditingContext ec = ERXEC.newEditingContext();
>>>     ListPageInterface lpi = (ListPageInterface) 
>>> D2W.factory().listPageForEntityNamed("AppUser", session()); 
>>> 
>>>     EODatabaseDataSource ds = new EODatabaseDataSource(ec, "AppUser");
>>> 
>>>     ERXFetchSpecification<AppUser> fs = 
>>>         new ERXFetchSpecification<AppUser>(AppUser.ENTITY_NAME, 
>>> AppUser.IS_ACTIVE.eq(true).and(AppUser.USER_TYPE.eq("Vendor")), null);
>>> 
>>>     ds.setFetchSpecification(fs);
>>> 
>>>     lpi.setDataSource(ds);
>>> 
>>>     ((D2WComponent) lpi).d2wContext().takeValueForKey("ListVendor", 
>>> "navigationState");
>>>     ((D2WComponent) lpi).d2wContext().takeValueForKey("Vendor", 
>>> "userTypeKey");
>>>     
>>>     return (D2WPage) lpi;
>>> }
>>> 
>>> I am also adding that userTypeKey so I can target rules like this:
>>> 
>>> 100 : (pageConfiguration = 'ListAppUser' and userTypeKey = 'Vendor') => 
>>> displayNameForPageConfiguration = "Vendor List" 
>>> [com.webobjects.directtoweb.Assignment]
>>> 
>>> Maybe there is a better way? If I select to edit a Vendor, I wanted rules:
>>> 
>>> 100 : (pageConfiguration = 'EditAppUser' and userTypeKey = 'Vendor') => 
>>> navigationState = "ListVendor" [com.webobjects.directtoweb.Assignment]
>>> 100 : (pageConfiguration = 'EditAppUser' and userTypeKey = 'admins') => 
>>> navigationState = "ListAdmins" [com.webobjects.directtoweb.Assignment]
>>> 
>>> then I thought that what I should be using is inheritance.  Vendor inherits 
>>> from User, Administrators inherit from User. In the past, I would have 
>>> created a User with boolean attributes for  Vendor, Client, Employee, 
>>> Admin. After all a user can be both an employee and a vendor.
>>> 
>>> How are youse guys doing this?
>>> 
>>> Ted
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
>>> Help/Unsubscribe/Update your Subscription:
>>> https://lists.apple.com/mailman/options/webobjects-dev/jlmiller%40kahalawai.com
>>> 
>>> This email sent to jlmil...@kahalawai.com
> 

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to