Barney, Roland, thanks for your replies to this: they jarred me into rethinking this corner of the design and it seems i've come up with a much better solution using both inheritance and composition. i'm going to try and implement it to see if it'll work out as i have it envisioned.
:) nando -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Thursday, October 28, 2004 2:23 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] calling a supertype from outside the subtype A better way to handle it would probably be to have the subtype's DAO do a super call to the supertype's DAO to persist the values bound to the supertype (I assume they're in different tables?). That way the fact that the supertype's DAO is being called is an implementation detail, not an architecture decision. >From what you describe, composition is definitely what you want. I'm not sure your exact setup, but it sounds like you need three distinct objects: Portlet, Location, Page. Ideally, each Page has a list of Locations that it contains, and each Location is associated with a given Portlet. What it sounds like you've got, on the other hand, is that Portlet extends Page. If inheritance figured into these three objects at all, you'd want Page to extend Portlet. cheers, barneyb On Thu, 28 Oct 2004 02:08:24 +0200, Nando <[EMAIL PROTECTED]> wrote: > Ok, so here's the situation. Perhaps my example wasn't the best. > > I'm passing the subtype into the supertype's DAO. Here's the relevant > snippet to give a sense of it. > > <cfqueryparam cfsqltype="cf_sql_integer" > value="#variables.thisContentObj.getSuperIdPage()#" />, > <cfqueryparam cfsqltype="cf_sql_varchar" > value="#trim(variables.thisContentObj.getStrContentType())#" />, > <cfqueryparam cfsqltype="cf_sql_integer" > value="#variables.thisContentObj.getIntPosition()#" />, > <cfqueryparam cfsqltype="cf_sql_varchar" > value="#variables.thisContentObj.getSuperStrLang()#" /> > > There were 2 values from the supertype that i needed - to get this working > for the moment i added getters - getSuperIdPage() and getSuperStrLang() - > getStrContentType() and getIntPosition() are both in the supertype only - > they work fine as is. > > As it turns out, I could as well get these values from the subType, as they > are shared, duplicated actually for convenience - i just got a little fixed > on the idea that they should come from the supertype. > > So the design flaw may be more in my database structure, as i'm duplicating > a few values rather than running a lot of joins in my gateways for > performance sake - or it may be in the way i'm passing the subtype into the > supertype's DAO - but in context this seems to make a lot of sense to me. Or > it may just be my silly idea that the duplicated data should come from the > supertype. > > Or it may be that i should be modelling this relationship using composition. > The "supertype" handles 2 things, it defines a position (on the webpage) for > the subtype - and it defines exactly "the type" for the rest of the > application, as if Vehicle would have a vehicleType attribute that could be > Car or Motorcycle or Truck, and it also had a location attribute (call it a > garage or a parking place) to allow any type of vehicle to park there. > > In any case, the only reason i'm drawing this issue out is to see how people > approach this. Again, passing the subtype into the supertype's DAO seem like > a good move, but now i'm not so sure. > > -- Barney Boisvert [EMAIL PROTECTED] 360.319.6145 http://www.barneyb.com/blog/ I currently have 0 GMail invites for the taking ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
