> I am no expert in > Object Oriented Programming, and I'm pretty sure I am loosing the plot somewhere > with the following cfc, I would really appreciate some expert input from someone > (Sean where art thou)..
Rockville, Maryland - at CFUN :) Hmm, well, this example is a bit overwhelming to try to think through... I'll give what guidance I can... > I believe I need to > lock any access to the object as its in the server scope, not sure yet whether > it gives better performance creating the object only once in the server and lock > access to it, or recreate the object every time and not having to lock access to > it, I believe its the first one. Depends. First off, you do not necessarily have to lock access. You don't need locking for data integrity - only for race conditions. And a lot depends on how you want your CFC to behave. If a CFC is stateless (has no data in "this" scope or "variables" scope) then you don't need to lock. If a CFC is stateful (uses "this" scope or "variables" scope) then you probably shouldn't store it in "server" scope anyway - "session" or "request" scope would make more sense. In your case, it looks like you have a stateful CFC that needs to behave like a "request" scope variable since you're storing per-request data as far as I can see. In other words, your business logic mostly precludes any savings you might get by trying to only instantiate the CFC once - because you need a separate instance for every request anyway I think! However, see below for how I've reworked your code... > request.result.objError.fnConstruct( > request.result ); > request.result.objError.fnDisplay( request.result > ); This certainly does look a bit odd. When you construct the error object (and please use 'init()' for your constructor for consistency with how everyone else seems to be doing it! :) you could pass in the 'result' object and the error object should remember it - so you don't need to pass it in again on subsequent calls. > But I can't really > tell you why, but I'm pretty sure its not a good thing having to pass itself > back with request.result Your gut feeling is correct. Only if the error object were a stateless service would this be expected behavior. > <cflock You don't need cflock if fnExecute() is stateless. (Why do you have 'fn' as a prefix? It makes the code hard to read - and it's obviously a function because you're calling it!) > request.result = > server.objProcess.fnExecute( "this string means nothing" > ); > request.result.objError.fnConstruct( request.result > ); If fnExecute() returns a struct with a fully constructed error object, it really should pass the struct into the error object at construction so the calling code doesn't have to do that (i.e., fnExecute() should call fnConstruct() - or rather init() - on the error object in the returned struct). Make sense? > request.result.objError.fnDisplay( request.result > ); See above. This code probably ought to look like this instead: request.result = server.process.execute( "blah" ); request.result.error.display(); execute() creates the struct, populates the error member with a fully-constructed error object like this: result.error = createObject(...).init( result ); return result; The error object's init() method does this to remember the enclosing struct: variables.parent = arguments.parent; The error object's display() method refers to variables.parent for the enclosing struct. > this.result = > structNew(); Don't use "this" scope - public data is a Bad Thing(tm)! Encapsulate it - use "variables" scope and provide get / set methods if necessary. Having said that, the process object should probably be stateless anyway and not use "this" scope or "variables" scope at all. > <cffunction > access="public" > name="fnExecute" > output="false" > > returntype="struct"> ... > <cfset structUpdate(this.result.error, >"isError", true)> > <!--- Append the error > message ---> > <cfset > this.result.objError.fnAppend( this.result, 'this is the message ' > )> Use a local variable for the result struct instead of "this" scope: <cfset var result = structNew() /> (at the top of the execute() function). Now your process is stateless and can live in "server" scope. Hope that helps / makes sense? --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
