I wouldn't worry too much about where things like lists are stored. Presumably you'd persist them in some kind of way (database, maybe XML file), but all you need is a ListService.cfc that provides access to them. If might query a db (or call a DAO to query a db) or it might store them in session or application scope, but start with the interface: ListService.getListByID(ID: int), ListService.getListsforUser(UserID: int), etc. would be candidate methods. If you're getting started, just throw a cfquery inyto your list service as now you have a good overall structure and then you can drop in a DAO to do the db stuff (or change to caching in session or application scope) without breaking your model interface.
Best Wishes, Peter On 7/3/07 9:55 AM, "Kowalski, Dana A ERDC-CERL-IL Contractor" <[EMAIL PROTECTED]> wrote: > Yes Lists would have an id and a name, and list items would be the items from > the list. In reality the lists you see would be based on your login only. > That is where my original question lies I suppose. I was thinking they should > all be put in session because it pertains to the individual user mostly.... > Except for the application level userSecurity. > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando > Sent: Monday, July 02, 2007 7:35 PM > To: cfcdev@cfczone.org > Subject: Re: [CFCDEV] Questions migrating to OO > > Hi, > > I think one of the most important points to keep in mind is to keep your > design practical. A lot of times in introductory texts on OO you see objects > like Airport, Airplane, Wing, JetEngine, Passenger, Pilot, etc ... and you > get the impression that to build an application in OO, you need to put every > concept you can think of in your design. > > Not so. If Airport isn't "doing anything" in your app, you don't need an > object for it. > > So, for instance, you have here > > List Object - Would handle the overall lists. > ??? > > What is a list? A collection of list items? Is that what you mean here? What > defines a list? A unique name? Probably an ID (ListID)? Probably a UserID > that identifies the list as belonging to a user. If i'm understanding you > correctly, and your users need to create lists by giving them a name like > "Shopping on Tuesday" - then you have a candidate for an object named "List". > But it doesn't make sense to me at all that a list object would be stored in > application scope. Why? Because you almost certainly have multiple lists in > your application. I'd put it either in session scope, perhaps, if you're > doing some sort of validation with the ListName for instance and you want to > persist the form data in the List object, or just leave it in request scope. > > <cfcomponent displayName="List" hint="I'm a List that belongs to a certain > User" output="false"> > > <cffunction name="init" access="public" output="false"> > <cfargument name="ListID" type="string" required="false" default="" > /> > <cfargument name="UserID" type="string" required="false" default="" > /> > <cfargument name="ListName" type="string" required="false" default="" > /> > <cfset setListID(arguments.ListID) /> > <cfset setUserID(arguments.UserID) /> > <cfset setListName(arguments.ListName) /> > <cfreturn this /> > </cffunction> > > > <cffunction name="getListID" access="public" returntype="string" > output="false"> > <cfreturn variables.ListID /> > </cffunction> > <cffunction name="setListID" access="public" returntype="VOID" > output="false"> > <cfargument name="ListID" type="string" required="true" /> > <cfset variables.ListID = arguments.ListID /> > </cffunction> > > > <cffunction name="getUserID" access="public" returntype="string" > output="false"> > <cfreturn variables.UserID /> > </cffunction> > <cffunction name="setUserID" access="public" returntype="VOID" > output="false"> > <cfargument name="UserID" type="string" required="true" /> > <cfset variables.UserID = arguments.UserID /> > </cffunction> > > > <cffunction name="getListName" access="public" returntype="string" > output="false"> > <cfreturn variables.ListName /> > </cffunction> > <cffunction name="setListName" access="public" returntype="VOID" > output="false"> > <cfargument name="ListName" type="string" required="true" /> > <cfset variables.ListName = arguments.ListName /> > </cffunction> > > </cfcomponent> > > So, if you have multiple lists, do you need an object to represent all of > your lists? Called "AllMyLists" or "UserLists" perhaps? > > I don't think so. Why? Because your users will probably not need to perform > any operations on all their lists at once ... especially in a way that would > lead you to represent them all in a business (or collection) object. When > Users are dealing with Lists, functionally, they do so One_At_A_Time. > > You can still have an option in your app to delete all your lists in a > Gateway for instance. That's about the only thing i can think of that a user > would want to do with all their lists at once. There's no need at all to load > all a User's Lists (and ListItems!) into a UserLists object to delete them. > There's no purpose to that. After the User clicks on a link that says Delete > All My Lists, you just get them to confirm it somehow in the UI, and once the > confirmation comes thru, you call DeleteAllUserLists() in a gateway function, > passing in the UserID, and that function simply deletes all the lists of that > user from the database. > > Does that help? > > Nando > > > > Hi, > I'm still new to a lot of OO stuff and coding CF procedurally for a > few > years, and I had some questions! > > I'm trying to migrate this app I have to OO and run it under > model-glue 2.0 > (if that matters). It is a to-do list manager, similar to remember > the milk > et al, but in CF and run locally mostly for my dev tasks. Anyhow, I > ALWAYS > get tripped up in architecture when it comes to OO. If someone had a > few > minutes to scan the below and offer any opinions/advice it would be > appreciated, I'm very green to this so shouting is acceptable :) > > > Breakout > ========= > List Object - Would handle the overall lists. Stored in application.x > + dao > + gateway > > List Item Object - would handle specifically items in a list, and I > guess > would be a dependancy of the list object? Stored in application.x > +dao > +gateway > > User Object - would store username, roles, email etc. Stored in > session.x > +dao > +gateway > > UserSecurity - would take a user object and perform password > changing, role > based security, etc. Stored in application.x > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the > instructions at http://www.cfczone.org/listserv.cfm > > CFCDev is supported by: > Katapult Media, Inc. > We are cool code geeks looking for fun projects to rock! > www.katapultmedia.com > > An archive of the CFCDev list is available at > www.mail-archive.com/cfcdev@cfczone.org > > > > > You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org
