I like the top option. It's actually pretty close to an MVC setup. If I were you I would set up the directories that way and make the public and admin directories circuits (so you'd have leaseAdmin, leasePublic, rentAdmin, and rentPublic). You would have to reference the queries as "../queries/qry_getstuff.cfm" which isn't pretty, but should work long enough to get it off the ground.
Then, once the app is done you can start thinking about MVC. First make, each of your queries directories circuits. Make a fuseaction that calls each query. Then replace the "../queries/" references with references to the fuseactions. (You can do that using FuseQ, CFModule, or CF_Call. They're all pretty straightforward. I'll show you how if you're interested.) At that point, you would be up to a model-presentation scheme, which is what I do now. You could also go all the way to MVC. From that point, you would need to create a new circuit in each section, move all of your display files to that circuit, wrap them in fuseactions (as you would have already done with the qry_ files) and call the new fuseactions from the old circuits. Once all that's done, you can take advantage of the new flexibility. You may choose to group all of your admin circuits together, for example. If you end up adding a fuseaction that needs data from both rents and leases, you'd be able to do that easily without duplicating any code or messing with the directory structure. I'm sure that's more than you care to bite off at this point, but if sometime down the road you want to learn about MVC, the structure you chose is a great starting point. :) Patrick > -----Original Message----- > From: Kathryn [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 10:42 AM > To: [EMAIL PROTECTED] > Subject: Question on directory structure > > OK, here is my latest project. I am doing this "by the book"! The customer has already seen/approved the wireframe and the prototype. I am now working up a Mind Map. (I haven't even begun the db, and it's killing me; I love db design!) > > The application is to maintain and display information on the leases on property my company holds. We have a few hundred branches, so the amount of data is pretty small. > > There will be a public side and an admin side of the application. On the public side, users will be able to see, for an example, current lease information on the properties over which they have managerial control. So I will have to run a query and display the lease information. On the admin side, a very limited number of people will be able to update information on the leases. Again, I will have to run a query and display a lease form. Obviously the queries will be basically the same. There are alse sections on rent information, renovation information, etc. Each of these sections also has a public and admin side. > > I am considering the following file structure: > > Lease > -----queries > -----public > -----admin > > Rent > -----queries > -----public > -----admin > > etc. > > In my original mind map, I had the structure set up as > > Public > -----Lease > ----------Query > ----------Display > -----Rent > ----------Query > ----------Display > > Admin > -----Lease > ----------Query > ----------Display > -----Rent > ----------Query > ----------Display > > but the revision above seems to make more sense. > > So...are there any strong pros and cons that you all can see in the revised file structure? Any warnings, war stories, etc. that you would share? > > Thanks. > > Kathryn Butterly > Web Developer > Washington Mutual Finance > 813 632-4490 > [EMAIL PROTECTED] > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
