>From reading your post, your solution sounds more like a global UDF
whose methods are called with the data stored in the client scope than a
true flyweight pattern (e.g., a shared, type-specific object for all
users).
But after reading this thread we were testing some ideas.
All of our CFCs use private variables (variables. not this.) and
support two related methods: setFromStruct and getAsStruct. setFromStruct
takes a structure, examines its key names, looks for any similarly named
setters (e.g., key is name maps to setName) and calls the appropriate
methods. getFromStruct simply returns variables.
We wddx'd getAsStruct and saved the result to the client scope.
On the next page hit, we retrieved the client variable we had just
saved.
We have an application scoped object called ObjFactory, which has the
method getObject(typeName, struct). getObject basically creates an
object of the specified typeName, initializes it and calls its
setfromStruct().
The calling template sets a request scope variable to the object
returned from ObjFactory.getObject(). (e.g., <cfset request.myObject =
objectFactory("com.myObject", client.wddxifiedData) />)
At that point, we have completely recreated the state of the
user-specific object and can treat it as a proper object.
Some adjustment would need to be made to handle public object variables
(this. scope), but it's not a big deal. Develoeprs need to use the
Bean-style convention of getVariableName/setVariableName. And some
consideration needs to be given to non default constructors (we always use an
init() method that returns this).
What do the forum members think of this approach?
Scott
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
