Thanks for the reply, here's some clarifications to my problem...
Let's give you a simple answer too ...
I'm really confused as to how to design DAO's for this. I
want to be able to have a pageManager cfc that takes a pageID as a field and
returns either a lecture or activity object.
To me it depends on whether this is for display or for
editing the page ... i'd do it differently in each case. What does your
PageManager do? Does it display the page? Edit the page? When we say "Page"
do we mean Page Content or just the title, meta description and name in the
link that a visitor clicks on to get to the Page.
The pageManager is going to basically handle anything the controller file
requires of pages. it will have methods like:
getPage() - retrieves a page based on an ID and returns a page object (with
any composite objects, ie lectures have faculties) for the view to render
getPageForEditing () - retrieves a page object for editing
addPage() - accepts a form submit and validates it, then if its good, insert
information to db
processEditPage() - an UPDATE version of addPage()
deletePage() - deletes a page record
getAllPages() - retrieves a query of all pages
getPageByType() - retrieves a query of pages by a type
etc...
when I say page I mean page and its content.
Basically the logic I want the app to follow is
pageManager.getPage(ID) is fired
*pageManager calls a DAO that retrieves a page record (this is where I am
having problems with)
pageManager decides what KIND of page it is by page.getPageType()
pageManger includes appropriate view, which will reflect on any additional
properties of the subclasses (like the lectureView will ask for
lectureNumber, while activityView will ask for activityContent.
Do I build multiple DAO's that corresponds to each different
subclass (ie: a lectureDAO and an activityDAO)?
For editing, i'd build multiple DAO's and i might consider,
but probably wouldn't compose the lecture and activity DAO's into the page
DAO. It depends on what you're actually doing when editing (whether you're
simutaneously editing information about the page AND the activity in one
form for instance.)
What i'd probably do is just have the pageID be a property
of Activity ... and i'd probably have some ID in there that indicates where
on the page the activity goes (which Container) if there is any chance at
all there there might wind up to be more than one bit of Content on the
Page.
Ahh I need to clarify that an Activity is a type of page, as is a lecture.
A page doesn't contain an activity.
Basically I will never actually retrieve a BASE page object. A page is
ALWAYS either an lecture or activity.
So from what you said, you're suggesting I build a LectureDAO and an
ActivityDAO. I was thinking of that, but then I realize
That in each DAO I will need to basically use the same code to read from a
base Page Table (for shared data like pageID, pageTitle, pageType, etc...)
while I don't mind writing those lines out twice, something tells me there
might be a more elegant way to do this.
I'm thinking that I might have to make something like a pageDAOfactory that
does something like this:
<cffunction name="getPage">
<cfargument name="pageID">
<cfset var page="">
<cfset var pageType = 0>
a simple db call to retrieve pageType based on ID, maybe like
pageGateway.getPageTypeByID(arguments.pageID)
<cftransaction>
<cfif pageType eq 1>
<cfset page = createObject("component",
"path.to.lecture").init() />
<cfset pageDAO.read(arguments.pageID, page)>
<cfset lectureDAO.read(arguments.pageID, page)>
<cfelse>
<cfset page = createObject("component",
"path.to.activity").init() />
<cfset pageDAO.read(arguments.pageID, page)>
<cfset activityDAO.read(arguments.pageID, page)>
</cfif>
</cftransaction>
<cfreturn page />
</cfunction>
thanks for the help so far...
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
<<attachment: winmail.dat>>
