True - since CMFX 6, CFLOCK is no longer "really" necessary. The threading model was improved and sessions should never "step on" each other.
That said, there is also no real reason to go into your code and remove all the CFLOCKs - except for performance reasons - which if you have none - no worries. Also, you can change the CFTOKEN to be a UUID in the CF Administrator. This basically makes the CFTOKEN a much longer string that is alpha-numeric with other chars. And, if you want to get real specific - enable J2EE Session, with will add a Jsession ID to the token. Matt Knight ► w: 972 361 9943 ► m: 214 213 4016 -----Original Message----- From: Schreck, Tom [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 9:22 AM To: [EMAIL PROTECTED] I agree that CFCs, as a general rule, should not directly output content. I use CFCs for my backend logic and data processing. That said, I do use CFCs occasionally to generate content usually within a <cfsavecontent> tag. I use this approach to 'cache' content that changes infrequently and store the content in a database prior to returning the content. I use the cfc to check the existence of the cached content in the database and return the cached content if it has not expired. If the content does not exist or has expired, I then re-generate the content, store it, then return it. I find CFCs are extremely useful in situations like this. I was hoping to hear that CFMX 6.1 would allow instantiated objects in the client scope. How useful would that be? I know you can use them in the session scope, but session scopes run the risk of colliding with other session if you forget to use <cflock>. I've heard that with CFMX you no longer need to lock session scopes. Thanks - Tom -----Original Message----- From: S.Isaac Dealey [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 20, 2003 9:09 AM To: [EMAIL PROTECTED] Subject: Re: CFCs CFMX 6.1 > In Aug's CF Dev Journal, Ben Forta introduces CFMX 6.1 and mentions > that "CFCs can now safely be placed in a variety of scopes" but does > not mention what those scopes are. Does anyone know what > modifications have been made to CFCs with the new release of CFMX 6.1? > Thanks - > Tom Schreck Iirc he's just referring to them fixing the page context(?) bug. You can output content directly from a CFC stored in the application or session scope. I'm with Sean Corfield and other OO folks on that one tho -- I don't think display should be output directly to the page within a function or cfc method (now that I have a better understanding of what they were talking about). Not because of any OO principals but just because it breaks the metaphor of functions. And the default output="true" _should_ have been false to make the default comparable to CF5 UDF's. It drove me insane the first time I ran into it trying to figure out why I couldn't get <a href="#myfunction()#"> to work because it was inserting white space into the output before the function call, but not with <cfset myvar = myfunction()> ... that's what I mean by breaking the metaphor. You can use writeoutput() to do the same thing in a CF5 UDF but it has to be explicit and even then I don't recommend it for the same reason. s. isaac dealey 972-490-6624 team macromedia volunteer http://www.macromedia.com/go/team chief architect, tapestry cms http://products.turnkey.to onTap is open source http://www.turnkey.to/ontap ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org ----------------------------------------------- To post, send email to [EMAIL PROTECTED] To unsubscribe: Send UNSUBSCRIBE to [EMAIL PROTECTED] To subscribe / unsubscribe: http://www.dfwcfug.org
