Sammy: Thanks for your response. I am concerned about memory space allocation because I'd like to understand how exactly the server processes a cfcomponent so I can better standardize my component implementations. Adobe does not readily provide tools to see how the CF Server is parsing through a component line by line - so call it an exercise in curiousity. I'm working on finding something that helps me understand the server side in detail - perhaps you could recommend something. CFDebugger.com is the closest I've seen as a practical tool, cfperformance.com is a $49 pdf that discusses the underpinnings of the Java based server and CFML processing - if anyone has opinions on either of those, I'd be grateful.
Thanks for your other opinions. I love setting constants - the application scoped stringNull and many other variables I set is a technique to avoid writing "" everywhere. In general, it is not good practice to stick literals in your code. It is much cleaner (in my own view) to declare literals as constants upfront and reuse those references in the rest of the application. As for having application scoped variables in the CFC's - it works great for my application - there's not much chance of me porting these same CFC's to other applications because this application is enterprise wide - it is not one of a set of very separate mini applications that might benefit from calling from a standard library of CFCs. When making programmatic decisions, it's often theory against practice. Sometimes forcing your code down a OO "purist" pathway makes your life more difficult instead of easy - in this case, keeping the CFC completely sheltered from the 'outside' world wasn't worth the advantages gained by calling constants. Application scoped constants are the only exception I make. On balance, this technique works nicely for my applications and it also means it is just another way of reducing ambiguity / human error down the line whilst affording a quick way of making a change if needed. Thanks for the pointer to Raymond Camden's CFC scope summary - I learned about the "Super" scope which I hadn't heard about yet. Finally, I didn't intend to not scope the addressTypes (in fact the truth be told, I only declared the others because I was sending my code to this list! And had forgotten to scope that one!) I do that because I know that by being declared in an unnamed scope within a CFC, it's going to be processed as a variables scope. Jason D -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sammy Larbi Sent: Thursday, November 02, 2006 5:01 AM To: [email protected] Subject: Re: [CFCDEV] Component initialization and memory space allocation Hi Jason, My first thought is, "why are you worrying about memory space allocation?" Do you expect to run into problems? Even if there is a difference, it is likely to be very minute, as it appears you are storing the same information in the same manner either way. The only difference is, in one way you are setting the variables to stringNull, which I presume would likely be smaller number of bytes than something the client code would put into the init function. But, my guess is that doesn't matter, as those values are likely to not remain null. Two other thoughts I had, for which you did not ask opinions (but I will give anyway =)) : 1) As I see the addressTypes variable being used, it does not appear to be properly scoped. Did you intend this? 2) Regarding the use of application.stringNull - I don't think many think it is good practice to have your cfc's rely on specific variables in the global scopes like that. Ray Camden's "Scopes in a CFC" pdf (http://ray.camdenfamily.com/downloads/cfcscopes.pdf) mentions that "in general you should not refer to these scopes inside a CFC. When you do you are making your CFCs less portable between applications." Personally, I feel you shouldn't rely on specific variables in these scopes - since I see nothing wrong with relying on a scope itself, if it will always be there, in that light. If you need to, I might prefer to put that in the request scope, and cfinclude a config file which sets it to be sure it is always there. Although, I must say I haven't thought at length about the differences between the two, so I could be wrong. And, out of curiousity, what is the value of application.stringNull? Following the principle of least surprise, I would expect it to be "", but then I wondered why you would bother putting it in a variable? Might it change? -Sam Jason Davey wrote, On 11/1/2006 3:14 PM: > > Hello: > > Can anyone tell me if there is a difference in memory space allocation > in the following two example implementations on initializing component > properties? The reason I ask, is that I'd prefer to call the init() > method from within the construction code but don't want to run into > variable memory allocation debugging down the line when the component > gets complex. > > Example 1: set component properties in the pseudo-constructor space > between the <cfcomponent... tag and the first function using inline code. > > <cfcomponent displayname="Address Class" hint="Address Class"> > > <!--- Property constructor for this class ---> > > <cfscript> > > addressTypes = "company,other,home,mailing,form"; > > variables.props = StructNew(); > > variables.props.addressStreet = application.stringNull; > > variables.props.addressCity = application.stringNull; > > variables.props.addressState = application.stringNull; > > variables.props.addressPostalCode = application.stringNull; > > variables.props.addressCountry = application.stringNull; > > variables.props.addressType = application.stringNull; > > </cfscript> > > Example 2: set component properties in the pseudo-constructor space > between the <cfcomponent... tag and the first function calling a > init() function. > > <cfcomponent displayname="Address Class" hint="Address Class"> > > <!--- Property constructor for this class ---> > > <cfscript> > > init(); > > </cfscript> > > ... > > The init() function. > > <cffunction name="init" access="public" returntype="address" > output="false" displayname="" hint="I set values to address instance > properties."> > > <cfargument name="argStreet" type="string" required="false" > default=application.stringNull/> > > <cfargument name="argCity" type="string" required="false" > default=application.stringNull/> > > <cfargument name="argState" type="string" required="false" > default=application.stringNull/> > > <cfargument name="argPostalCode" type="string" required="false" > default=application.stringNull/> > > <cfargument name="argCountry" type="string" required="false" > default=application.stringNull/> > > <cfargument name="argType" type="string" required="false" > default=application.defaultAddressType/> > > <cfscript> > > addressTypes = "company,other,home,mailing,form"; > > variables.props.addressStreet = arguments.argStreet; > > variables.props.addressCity = arguments.argCity; > > variables.props.addressState = arguments.argState; > > variables.props.addressPostalCode = arguments.argPostalCode; > > variables.props.addressCountry = arguments.argCountry; > > variables.props.addressType = setAddressType(arguments.argType); > > return this; > > </cfscript> > > </cffunction> > > Thanks for any thoughts, > > Jason D. > > > 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] 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] 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]
