Re: Subclassing and Reusable Components
Re: Subclassing and Reusable Components
- Subject: Re: Subclassing and Reusable Components
- From: Chuck Hill <email@hidden>
- Date: Mon, 25 Oct 2004 21:29:45 -0700
At 12:16 AM 26/10/2004 -0400, Jaime Magiera wrote:
>On Oct 25, 2004, at 11:13 PM, Chuck Hill wrote:
>> Does that mean you are using EOF inheritance? Do "SoftwareProject" and
>> "MediaProject" have data and behavior that Project doesn't?
>
>I subclassed because they have some different data: "MediaProjects" has
>keys for downloadURL, streamURL, etc. "SoftwareProject" has stuff like
>versionNumber, etc.. Every "Project" has date, description, links and
>discussion.
>
Seems right.
>> You mean they don't? Whoa! They should if you are using EOF
>> inheritance.
>> At this point, I am not quite clear on where you are in this. Are you
>> just
>> asking about design? Have you started to model this and run into
>> problems?
>
>I had tried several months ago to just subclass the Projects. Yes, the
>discussionThreads were in the sub-classed objects. However, I kept
>getting all sorts of data integrity errors when trying to save to the
>database. So, I thought I had done something wrong.
>
Ah, right. Subclassing is an OO concept that does not translate well into
a relational database. If you use something other than single table
inheritance you will not be able to apply FK constraints at the database
level. I just leave them off and trust in EOF. If you feel that you must
have FK constraints then either use single table inheritance or don't use
it at all. The former seems to be the sensible choice.
>If I subclass Project, the subclass has it's own table. However, those
>subclasses share the same PK index count, correct? ... and EO knows to
>check each subclass table? The EO manual didn't quite give me enough
>info to understand the process.
>
EOF knows but the database does not. You will get DB exceptions if you try
to apply FK constraints that do not hold.
>> The answer to that depends on what is different / what you want to be
>> different in each sub-class. WOSwitchComponent can also be used to
>> switch
>> UIs on the fly.
>
>Well, since each individual project type has some common data fields
>and some unique data fields: Create a WOComponent that displays the
>common data in an identical format (e.g. Title and Date, Links, which
>are common to all). Then have the data unique for each Project type
>further down in the page. My thought was to have an EOEnterpriseObject
>variable that I can pass any of the project types in with. Then add
>components using boolean methods bound to WOConditionals. Those
>conditionals would contain the project type specific data. However, if
>I pass the project into the component coerced to EOEnterpriseObject,
>I've lost the ability to get the subclass. Another thought would be to
>use a boolean to check for the existence of the keys and bind the
>conditionals to those. I'm pulling this out of the air though and don't
>want to do something in a far more complicated then it has to be :)
>I've had components for each project type built and functioning for a
>while. However, it seems really wasteful to duplicate so many times. My
>framework is severely bloated.
>
I'd have one component that displays the common stuff, and one for each
subclass for the unique stuff. Both would get used to display different
parts of the same EO. You can use the Entity name of the object to map to
the relevant editor component and get WOSwitchcomponent to show the
correct one. In the subclass specifc editor subcomponent just cast the EO
to what it really it.
Chuck
--
Chuck Hill email@hidden
Global Village Consulting Inc. http://www.global-village.net
_______________________________________________
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