Hi Joe, I'll just answer the easier bits and leave the rest to the clever people.
[Nando must type faster than me - I'll post this anyway - hope it doesn't muddy the waters] > Also, if there's a good CFC/OO tutorial or reference out there, > please let me know. I'd like to know too :) There are lots of bits and pieces. You might want to consider one of the excellent general OO references (not CF specific) like Craig Larmans "Applying UML and Patterns" (much more general than it sounds). >I've read the CF documentation and Livedocs. I've > started reading some of the MVC stuff on the web, but it's still a > little above my head. I'm really having trouble differentiating between > the model and controller layers. Very basic rule of thumb - your controller doesn't know about your database, and your model doesn't draw things or know what page is coming up next. > > 1. I use CFC instances in persistent scopes--mostly session--and create > a unique named lock inside each instance. I lock any code in the CFC > that sets its properties using the named lock. My question is: do I > still need to lock the scope when I call an instance method from a page? > (I'm moving towards making CFC properties only accessible through its > methods, but some of my earlier work uses the This scope.) What if the > method reads or writes to a database or to another variable in the scope > but outside the CFC? There's a fair bit written about locking in CF. This is not specific to CFCs. There's no simple answer. You have to lock to avoid race conditions, but identifying and correcting race conditions is a bit of a black art. > > 2. If a CFC extends another CFC, does the init() method need to call > Super.init()? If so, why doesn't this create two instances--one of the > "parent" CFC and one of the child CFC? Does super.init() automatically > receive arguments passed to init(), or do they have to be explicitly > passed to super.init()? init() doesn't create the instance. CreateObject() creates the instance. init() isn't even automatically called, it's just a convention. In general it would be a good practice to call super.init() unless you are explicitly replacing the superclass code in the subclass. Arguments aren't automatically passed - the super call is just another function call as far as context is concerned. > > 3. If a method overrides a method of a base CFC, does the child method > need to to call super.myMethod()? What if the child method is only > intended to override part of the parent method's functionality? For > instance, the method may set a number of properties, but the child > method only needs to override some of those properties. Also, similar to > question 2, does super.myMethod() receive arguments passed to > myMethod(), or must they be explicitly passed to super.myMethod()? > Your choices for overriding are: a. call the super method, then do your own thing b. do your own thing, then call the super method c. don't call the super method, just do your own thing d. break down the super method logic into pieces and put each in its own method. Change the super method so it just calls all the pieces one after the other. Then override the pieces you want to change. This is called the "template method" pattern. > 4. How is a method of one object made available to the methods of > another object? You can either a. keep the object in an instance variable, b. pass it as an argument to a single method c. call another method on some other object that returns the object you want d. some combination of these > Can a property of the second object be a reference to > the first object? Yep. >If so, is the first object actually passed by > reference or by value (by duplication?)? By reference > For example, in this code, can firstCfcMethod() call > Variables.SecondCfcReference.secondCfcMethod()? Yep. BTW, cfproperty maybe doesn't do what you think it does? In object-speak "property" is a synonym for "instance variable". Unless you're creating webservices, cfproperty has nothing to do with instance variables. > > 5. If a CFC (FirstCfc) property is a reference to another object > (SecondCfcInstance), can SecondCfcInstance "see" the FirstCfc's > properties and methods? > Public methods - yes. Package methods - if in the same directory. Private methods - no. Properties (i.e. instance variables) in the "variables" scope - no Properties (i.e. instance variables) in the "this" scope - yes > Below are outlines of the CFCs in the app I'm currently working on. If > there are glaring (or minor) errors, I would be very grateful to have > them pointed out and perhaps explained. > Wow. I'd like to go off on a tangent here and recommend that (if you haven't already), you have a look at Subversion and CFCUnit. It sounds like you're going to want play around with a few different approaches, and if you set up version control and automated testing you will remove 90% of the stress in doing that (other than that next deadline...). Jaime Metcher You are subscribed to cfcdev. To unsubscribe, please follow the instructions at http://www.cfczone.org/listserv.cfm CFCDev is supported by: Katapult Media, Inc. We are cool code geeks looking for fun projects to rock! www.katapultmedia.com An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
