Ahhh ... but wait a sec. this is a ContactManager - so since we're dealing with one contact at a time, from the perspective of thisContact, it's reduced to a one to many relationship, much easier to maintain that, perhaps as a property of the Manager itself.
In a multistep process, i think i need to distinguish between AddContactToGroup() and PersistContactToGroup(), in case a user abandons or cancels the process. But this is enough to get me started. Thanks Roland! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nando Sent: Friday, July 22, 2005 10:53 PM To: [email protected] Subject: RE: [CFCDev] Managers Good. I like it. What i wasn't too clear about is what would take the place of, or function like a bean in a case where you have a many to many relationship like that. I had a vague idea i might need some sort of ContactGroups entity in there with getters and setters, a place to maintain state (in memory) until the process clears validation and moves through all it's steps. And that's where i got lost. But for these specific functions, maybe that's not needed. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Collins Sent: Friday, July 22, 2005 10:19 PM To: [email protected] Subject: RE: [CFCDev] Managers Well it depends. You manager could either directly manipulate your persistence layer with SQL, etc. or you could even abstract that out and create a data access layer. I personally would just write right to the persistence layer at this point unless you have a need to support multiple persistence mechanisms. I can count the number of times I've personally benefited from completely abstracting my data layer on one finger (and it's the one in the middle ;)). So you could do something like this (in very loose code): <cffunction name="AddContactToGroup" returntype="void"> <cfargument name="contact" type="Contact" required="true"> <cfargument name="group" type="Group" required="true"> <cfquery> INSERT contact_groups (contact_id, group_id) VALUES (#contact.getID()#, #group.getID()#) </cfquery> </cffunction> It really doesn't have to be any more complex than that. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Friday, July 22, 2005 3:54 PM To: [email protected] Subject: RE: [CFCDev] Managers This is great. Sometimes i just don't know when / whether to take the natural relationships "seriously" in a model, as in - Does a Newsletter have Recipients (Contacts), or does a Contact have a Subscription to a Newsletter. It's easy to get trapped in a sort of circular thinking and not have any clear pathway out of it in a case like this. So what would just one of these methods look like? How would it work? AddContactToGroup() I don't quite get the implication in the diagram behind the (in contact : Contact, in group : Group) part, ... yet. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Roland Collins Sent: Friday, July 22, 2005 9:13 PM To: [email protected] Subject: RE: [CFCDev] Managers How about we start with some diagrams? The attached diagram is a very rough first pass at one way of tackling the problem. It treats each of the actors (contact, newsletter, group) as separate entities and then uses the Manager to deal with their interactions. This sounds like a candidate for some breeze-time :) Roland -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Friday, July 22, 2005 1:27 PM To: [email protected] Subject: [CFCDev] Managers I'm quoting Jared here: *classically "manager" is not the same as "factory" - managers maintain the state of their composed members, factories just create them and hand them back to the caller* The part i'm interested is "managers maintain the state of their composed members". Practically, here's the situation i'm looking at. I have a visual mockup in front of me. It's a multistep process that essentially allows a user to add/edit a Contact. There's the usual names, address, phone, etc in there. Then, the Contact can optionally belong to a Group - or several Groups. So there's a series of checkboxes there with the Group names. That's pretty simple The Contact can also be put on a Campaign (a series of emails) or several Campaigns. Now here, although a campaign as a series of emails in itself doesn't change per contact recieving the Campaign, there are properties involved that do or can change - startingDate, frequency, designTemplate for instance. The Contact can also receive a Newsletter. At the moment, there's only one Newsletter and either they receive it or they don't - but there's talk in the air of the possibility of multiple Newsletters. I know for sure there's composition in the air. How would you approach modelling this if you had more OO experience than i do? How could a manager help make sense of these somewhat complex relationships? I always hit a foggy patch whenever i run across what seems like it should be a simple case of composition. It can be hard to tell who should be composed into whom. Any help here would be appreciated. thanks, Nando ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
