But what if the section information is also accessed outside of the UserBean's context? Maybe each section has some properties that can be edited, and you want the section details page to show all of the users in that section.
In that case I might introduce a third CFC called UserSectionManager. This class would be responsible for managing the connections between users and sections. It would have methods for retrieving all sections for a given user, all users for a given section, adding and removing users from sections, etc. (Whether or not this class implements those methods directly or delegates them to a UserSectionDAO, UserSectionGateway, etc depends on the scope of your app)
The benefit of this approach is that it brings all of the logic concerned with the intersections between Users and Sections into a single place where it can be easily maintained.
I want to state again I'm just beginning to use OOP in the "real world" so there could be semi-sized holes in my approach.
On 1/17/06, Ben Nadel <[EMAIL PROTECTED]> wrote:
So Bill,
All the UserDAO methods take a UserBean instance - so would that mean that
the userBean would need getters and setters for the section keys (so that
they could make it to the DAO)?
Thanks for the help!
-ben
......................
Ben Nadel
Web Developer
Nylon Technology
350 7th Ave.
Suite 1005
New York, NY 10001
212.691.1134 x 14
212.691.3477 fax
www.nylontechnology.com
Sanders: Lightspeed too slow?
Helmet: Yes we'll have to go right to ludacris speed.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Bill Rawlinson
Sent: Tuesday, January 17, 2006 5:09 PM
To: [email protected]
Subject: Re: [CFCDev] Updating a Join table
based on what you told us it seems to me the only time the
secure_section_user_jn table will be written to is when the user is updated.
If this is the case I would have that logic in the userDao.
the userDAO isn't so much responsible for one row in a database table
as it is for persisting one entity from your model. As the user -
section relationships are a direct property of the user (from what I can
tell) then the userDAO is responsible for persisting that information.
Bill
On 1/17/06, Ben Nadel <[EMAIL PROTECTED]> wrote:
> Hey,
>
> Quick question, hopefully with a simple answer.
>
> I am exploring more OOP styles of programming and I have users, secure
> sections, and a join between the two:
>
> user
> secure_section
> secure_section_user_jn {has user.id and secure_section.id columns}
>
>
> I am trying to go about this via Beans, DAOs, and gateways. I
> understand that user DAO updates using user bean. But I am very lost
> at the join table update. I am envisioning a form that has the user
> info and then a list of checkboxes for the different secure sections
> of the site (small user management form).
>
> So, I have these two tasks:
>
> 1. Getting access keys for the given user (when going to an edit-type
> form) 2. Updating the user's access (when submitting the edit-type
> form)
>
>
> Who does this? Where do I get the access keys?
>
> Does the user bean have getters/setters for list of access keys (comma
> deliniated)? Do have an AccessGateway that has something like
> GetSectionsByUser()??
>
> Contextual notes:
>
> 1. Use access keys will really only be need by the user. I would never
> look at the join table outside of the context of a user, except
> looking up all users who have access to a given section.
>
> Please give me help, I am totally lost, and this is one of the last
> stumbling blocks on the way to my first OOP project.
>
> Thanks,
> Ben
>
> ......................
> Ben Nadel
> Web Developer
> Nylon Technology
> 350 7th Ave.
> Suite 1005
> New York, NY 10001
> 212.691.1134 x 14
> 212.691.3477 fax
> www.nylontechnology.com
>
> Sanders: Lightspeed too slow?
> Helmet: Yes we'll have to go right to ludacris speed.
>
>
>
> ----------------------------------------------------------
> 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]
>
>
>
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
----------------------------------------------------------
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]
----------------------------------------------------------
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]
----------------------------------------------------------
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]
