The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

CFC: Expose Thyself

posted under category: ColdFusion on January 17, 2005 at 1:00 am by MrNate

Weird little thing I found. I thought it up a couple weeks ago when the cf-talk list was bickering about CFCs and good encapsulation and so on. Here's a way to undo it all in one quick swoop.

A CFC can expose all of its private data. Just have a method return variables. Every private member and method is now yours for the taking.

Hey here's some bad coding advice. Too lazy to make getters and setters for all your variables?

<cfset myCFC.getVariables().privateVar = "new value" />

Too old to comment!
On Jan 17, 2005 at 1:00 AM M. Schopman (micha has underestimated the power of mschopman.demon.nl) said:
Or use cfinclude, and within that include all variables and methods are available in the variables scope.

That is the reason why I personally prefer cfmodule instead of cfinclude. With a cfmodule call you can provide variables which are encapsulated within the called template. You can misuse "caller.x" to return data to the cfc method for the cfc method returnvalue.

On Jan 17, 2005 at 1:00 AM Raymond Camden (ray who hates camdenfamily.com) said:
M - when you say, use cfinclude, do you mean INSIDE the method? If so, that makes sense. The code in the cfincldue is acting in the same context as the method, so of course it has access to private methods, members. Nothing is private when you are already inside the method.

On Jan 17, 2005 at 1:00 AM Micha Schopman (micha who wouldn't be caught dead at mschopman.demon.nl) said:
Raymond, yes this is the way cfinclude should work, but it can get you in some nasty situations.

I personally had several issues with a cfc stored in the server scope. Within one of the methods I used an include and for some strange reason cfparams in the included template failed to work. For some reason the variables weren't released. Even with new provided variables.

It must have been an user error, because I couldn't reproduce the error in a seperate case, but it made me think "have I hit a cfmx bug?"..

On Jan 17, 2005 at 1:00 AM Scott Barnes (scott who hates mossyblog.com) said:
its a known bug.

Incidently if your gonna use the above approach may aswell store your stuff in the variables scope and do away with having an extra custom method per object (execution and code wise)


On Jan 18, 2005 at 1:00 AM Sameer Kekade (samsoft24@aol.com or @gmail.com) said:
If you don't need your setters and getters to do anything more than just set and get properties (without modifying those properties), you might be able to save yourself the hassle of implementing all those set and get functions by building a little support framework. In the example below, there is a component called "support.cfc" which all components that need a lot of get and set methods should extend. Notice how the component "test_support.cfc" is free to set and get arbitrary properties without those set and get methods actually having been implemented. (This will also hold true if your component contains an instance of a component that extends support as opposed to extending support itself as in the example below.) I believe you can even scope variables (with or without "this") using this technique:

support.cfc

setVariable(varName, varValue);


support_test.cfc

returnVariable="baz" />
I'm sure there are better ways to implement this type of technique, but you get the idea.

On Jan 18, 2005 at 1:00 AM Sameer Kekade (samsoft24, who eats gmail.com) said:
The code again!

support.cfc




setVariable(varName, varValue);



support_test.cfc


     

returnVariable="baz" />

I'm sure there are better ways to implement this type of technique, but you get the idea.

Too old to comment!