Steve, Not a direct answer but one thing i notice is the use of the plural form "articles" - you might be better off using the singular form "article" when thinking about it - so that you are clear that this construct you want to build models a single article.
The next step is to think about attributes and responsibilities ... "I am an article. What do i know about myself ... what are my responsibilities - what do i need to do within this system." I know you're doing this, but it might help you to do it systematically so you don't get lost in all the possibilities. Probably most people need to approach it this way, even the very experieced. There are 2 ways i've read about for sorting this out, step by step. One is to use flash cards, the other is UML. In the flash card system, [Scott Ambler, The Object Primer] you can develop an object model by identifying the nouns in your system, User, Security, Article, etc. and then by running through the verbs or actions that you can think of, and seeing where they make sense, who should be responsible for taking care of this? Write them down as responsiblities on the cards. Use the first person to assume the role of the object, to see the system from the object's perspective. "Ok, let's see ... I'm an Article. I have an incoming request ... now i have to figure out if i can show myself to the person who is asking. Do i need help doing that, or can i do it alone? Then depending on what I (or We) determine, i need to get some data from somewhere, maybe it's the database, and deliver it to the presentation layer." As you go, you might find a few more nouns or objects that were not apparent ... and you might also find some verbs or methods that you didn't think of initally. Sort them out on your flashcards or in your UML model - shift things around until it seems to make sense. Ambler even suggests getting a group of people together, among them should be some people who know the "business" the system is to model really well, the business experts ... to develop the model on flash cards and act out the objects' roles and see if everything works as it should - refining the model as they go. He says it is one of the best ways to develop a model, but because it looks so low tech, he sometimes has trouble convincing people to go along. Then you might take a look at it from a more professional OO standpoint and check if you are "encapsulating what varies" and "favoring composition over inheritance", etc - you might then refactor your model. I tried to do this just in my head in the beginning. In fact, i don't think i even realized that what i was doing was trying to develop an object model. I just thought ... ok, what cfc's do i need. And it was very confusing. I've found that it really helps to use a technique to sort this out, especially in the beginning. I would suggest it highly. And i think it also helps to realize that just like in procedural code, there is no one right way to do something ... but in any case, the majority of experienced procedural programmers might agree on certain tendencies and vary on the margins. When we first started out writing procedural code, we wrote some pretty strange stuff, no doubt. Remember? But as time went on, the general tendencies that just make sense became clearer and clearer to us, and our procedural code became tighter, more efficient, more reusable, and more capable. It seems the same process happens when using CFC's in an OO style. CFC's can be used as just a programming construct - a convenient way to reuse code - or they can also be used as objects. In the beginning, i wasn't too sure of the difference. Now i'm not too sure of the implications sometimes in using one approach or another, for instance, why encapsulation seems so danged important to the experienced OO'ers. What's the benefit to tightly encapsulating my objects when i'm the only one working on the app? If you take a few steps on this path, there are more up ahead. In the meantime, it might be useful to give ourselves the permission to build a few somewhat sloppy apps and learn from them. I have a feeling you want to get this perfect the first time. Me too. ;-) -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steve Bryant Sent: Thursday, April 29, 2004 6:38 PM To: [EMAIL PROTECTED] Subject: [CFCDev] CFC interaction (take 2) I will get this eventually. In the meantime, I really do appreciate the help. OK, so I have an articles.cfc. One of its job is to serve up an article (recordset) when requested. Each article may or may not be available to the public and may have some sort of access requirement. I see two ways of doing this: Strategy 1: Tell articles.cfc what article is being requested and who is requesting it. In response, articles.cfc will check what permissions are needed to view the article and ask Security.cfc if the requesting user has the correct permissions to view the article. It will then return a recordset with either the article or some stuff that says (basically). "Sorry, you don't have the rights.". This means that articles.cfc has to talk to Security.cfc (either calling it through Application scope or instantiating it anew) and is less independent and therefore less modular. Strategy 2: Tell articles.cfc what article is being requested and the permissions of the person (or server) that is requesting it. In response, articles.cfc just has to check if those permissions are appropriate for the given article and then return the article or a "no can do" message. This means that articles.cfc is more independent and more modular, but that I have to store permissions information in my Session scope and that I would have to store it in Application-scope session tracking for web services as well. I would think that would mean that a web service couldn't call this method directly because a web service couldn't pass permissions into the method (or else the calling server could just send any permissions that it wanted to). It seems to me that strategy 1 is better, but this seems to be "coupling" and therefore wrong. What am I missing? A strategy 3 perhaps? Thanks and sorry for the barrage of questions to the list. =) Steve ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.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' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
