I wouldn't create separate CFC's for each group of people. I would create one people CFC and then one permissions CFC.
On the permissions CFC I would have methods that looked like: listPeoplePermissions(peopleID) - maybe use this on login to set a session variable addPermission(peopleID, permissionID) removePermission(peopleID, permissionID) listPermissionTypes() CFCs have built in permissions which I'm sure you're aware of. Hal also has some good thoughts down on paper for a proposed security model in fusebox applciations. The fusebox stuff can be filtered out if that's not your thing, it's a good read regardless: http://halhelms.com/writings/ProposedSecurityModel.pdf As for your database, I always use cross-reference tables to store permissions between two dynamic entities (ie, people and organizations). I always use a convention when naming my permission cross-reference tables - perms_peopleOrganizations - so that they are all together in a list of tables, and to make it a little easier on the next developer. I would imagine your permissions CFC would be in charge of managing these bad boys. Adam. > -----Original Message----- > From: Gyrus [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 20, 2003 3:57 PM > To: CF-Talk > Subject: CFC's and people management > > > Hi all, > > I'm planning an MX revamp to our bespoke CMS, and I'm wondering about > restructuring the way "people" are handled, using CFC's. > > In my current system there are "users" who can login to the > admin functions. > This works fine, most of the time. Only, when you get > "clients" who have > login accounts to access a client-only area, I've often found > myself having > to create "client accounts" for "users", so they can login to the > client-only area as well to see the content they're managing. > > (BTW, this is all based on having a frontend and a backend, > two separate CF > applications. Obviously this issue would be ironed out if > there's one site > that can be administered "from within" - something I'm > planning on trying.) > > It gets more complex when it comes to having company > "contacts" - some of > whom will be "users" - and maybe a more general category of > "people" (one > site I've built associated content items with one or more "people", if > there's an article about a specific person, or if the item is > a review of an > album, it links to the "people" table to specify the artists). > > I'm wondering whether I should just have one top-level > "people" table / > "person.cfc" that models and manages absolutely any types of > people in the > site. Then you'd maybe have subset tables / subtype CFC's like > "administrators", "users", "contacts", etc. In some cases > there might be > another level, e.g. person > administrator > developer, > depending on whether > "developer"s would need much extra information about them storing. > > I'm only starting out with CFC's, so I'm just wondering > whether this is a > valid, effective way to start thinking about remodelling my > CMS. Would I > just end up with too many table joins accessing all those > subset tables? Or > would the fact that this will be done in CFC's reduce this > problem by only > having any less-than-easy SQL joins in one central place? > > Any comments/thoughts welcome, > > Gyrus > [EMAIL PROTECTED] > work: http://www.tengai.co.uk > play: http://norlonto.net > PGP key available > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
