Steve, I'm over here smiling ... nice to see a fellow compatriot struggling up the hill.
I've found UML very useful at this stage. It's just plain difficult to visualize all your object relationships via code examples, or just by talking things thru. Have you checked it out yet? Argo UML is good, so is the community version of Poseidon. It's also very useful to understand HOW objects can relate with each other, how they can help each other out, both conceptually and in practice. What the code looks like. I think sometimes the more experienced OO people who have done this stuff in other languages don't realise that sometimes beginners don't know the mechanics of composition, extension, and simply using a related object in a method to grab a value. You could just initialize Security in a User method called login for instance and that would be a simple, effective way to have them work together. After playing around with OO in CF for the past several months, I can say that the art of building a "correct" model seems to be in anticipating how the application might change in the future, and seeing if you can encapsulate that in an object. For instance, just to get started, i did not separate out the database access into separate objects ... guess what happened. The NEXT interation of this application needs to work in MySQL ... so it would have been better to separate that out from the very beginning, as the SQL is different. Encapsulate what varies ... So i *think* that when people in the know about OO suggest separate cfcs for Security and User for instance, they have the experience to recognize that it might be better to loosely couple the two, so that they can each change and evolve separately. You might be equally concerned at this point with "how do i get the code to work ..." and "what is the right way to do it" in a vague sense. The "right" way to do it, as i'm beginning to understand it, is to encapsulate what varies or what could vary in future. But in the beginning, it might just suffice to play around with lots of different possiblities and just get a feel for the mechanics of how cfc's can work with each other. If we were not concerned about accomodating change or modularity, i suppose you could just put everything in one object. Why bother whether or not to have a Security object? But this would be similar to putting everything in one table in your database, or all your files in one directory. You can do it. It can be OK, but not optimal. Shalloway in Design Patterns Explained is encouraging his readers to encapsulate what varies or what could vary in the objects that we create. That way, when change does come, we only need to modify one object. Remember that you can always compose objects, that can mean either a) passing an instance of an object into the init() method of another object and storing it in the variables scope, or b) instantiating an object within a method of another object (the init() or any other method) and storing it in the variables scope, or c) instantiating several objects within a managerObject of some sort, storing them all in the variables scope, and having them work together (a common approach i think in Mach-II listeners) or d) simply invoking an object in the method of another object (var scoping the instance so it doesn't wind up in the object but just stays local to the method), get a value of some sort from the object, and let it "die". It does not take much resources from the server to simply invoke an object. I've timed it very consistently at 0ms. What you do within the object can take resources of course, but it will anyway. So don't be afraid to use this option if it makes sense. You can also always store objects and any instance data that remains consistent in the session or application scope - so you could store the user data for each user that logs in in an instance of session.user - or if you don't need the capability of an object to manipulate the user data once they log in, or don't need to use the functions of the user object to store more data along the way, then maybe it's enough to just use a simple boolean value, isLoggedIn ... or to put the session data in a structure for instance. in other words, if you don't need to carry the whole object in the session scope, then don't. But maybe you decide it's useful to do so ... maybe there is an interface in the app where the user can change their data and you think to yourself that it's worth it. I don't know if any of this is useful or not ... maybe some points were too simple. In any case, i'm very interested in developing a simple but effective approach to OO in CF. There are lots of guys out here that have developed a fairly sophisticated understanding of OO and have lots of good suggestions. While / if you're still struggling with the basics, don't let their fine nuances confuse you too much. It can be kind of like struggling with how to say "Can I have some milk, please?" in a foreign language and you get back a detailed discussion of the appropriateness of different tense conjugations and whether to use the polite or familar form in different circumstances. :) n. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steve Bryant Sent: Wednesday, April 28, 2004 7:38 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] CFC interaction (user log in) I certainly see your point. My thinking here is that my Security object _might_ later do other things then interact with a user. It might interact with a web service request later as well. Even if it didn't, it seemed appropriate to me that my Security object know the criteria for a User to have access, but that my User object should know that. Then I could use the same User object in a different site with a different Security object (if I can ever figure out how to set up my objects appropriately). At 05:04 PM 4/28/2004 +0000, you wrote: >Right on, I think you are going the right direction. > >Although I'm still unsure if a seperate security.cfc is necessary. >Afterall the methods in the security.cfc pertain to only a user. >CheckLogin() and login() preform actions for a user. I would put >checkLogin() in the user.cfc and in your pages uses <cfif >userObj.checkLogin()> for your logic. Or set it directly to a SESSION >variable like SESSION.isLoggedIn = userObj.checkLogin(). > >As far as modularity, if security.cfc relies completely on user.cfc, then >security.cfc is not modular at all and might as well be wrapped into the >user.cfc. > >my 2 cents > >-adam ---------------------------------------------------------- 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]
