It also depends on your model. As Bill said, the DAO really is the
place for this. There isn't a 1:1 relationship between DAOs and tables,
although it sometimes seems that way. I'm no OOP guru, just commenting
from my recent experience.
A thing to think about is how you model the user->sections relationship.
Instead of a list of sections as the value of the property, you may want
a structure keyed to all possible sections with true/false values like
this:
User.sections[section1] = true
User.sections[section2] = true
User.sections[serction3] = false
Etc.
This allows you to write a method like user.hasAccess(section)
<cffunction name="hasAccess" access="public" output="false"
returnType="Boolean">
<cfargument name="section" type="string" required="true">
<cfreturn variables.sections[arguments.section]/>
</cffunction>
That's off the top of my head, so don't take it as "good" code, just an
example.
The user is init'd with all sections = false, updates would "turn them
on".
I've used this technique before in a slightly different way and it has
worked pretty well.
anthony
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Bill Rawlinson
Sent: Tuesday, January 17, 2006 2: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]
