Hi folks,
I've got a CFC that I call 'Base'. It contains some general functions that might
be useful no matter what other CFC I might be in, and so most (if not all) of my
CFCs extend Base.
I work with another programmer on this particular project who likes to put just
about *EVERYTHING* into Application.cfm (we're using CFMX6.1).
For example:
<!--- Default date/time masks --->
<CFSet SQLDateMask = "yyyy/mm/dd">
<CFSet DateMask1 = "mm/dd/yyyy">
<CFSet DateMask2 = "d mmm, yyyy">
<CFSet DateMask3 = "mmm d, yyyy">
<CFSet DateMask4 = "dddd mmm d, yyyy">
<CFSet DateMask5 = "dddd mmmm d, yyyy">
<CFSet TimeMask1 = "h:mm:ss tt">
<CFSet TimeMask2 = "HH:mm:ss">
<CFSet TimeMask3 = "h:mm tt">
<CFSet TimeMask4 = "hh:mm:ss tt">
<!--- Set the common date variables. --->
<CFSet Today = Now()>
<CFSet Yesterday = DateAdd("d",-1,Today)>
<CFSet Tomorrow = DateAdd("d",1,Today)>
<CFSet FirstDayThisWeek = Today - DayOfWeek(Today) + 1>
... etc., etc.
That's all well and good. So, I've spent the last year or so trying to coax him
into using CFCs. His first complaint was that he didn't have access to all of
the nice variables that he's so used to having. (*sigh*)
So for the better part of a year or so our solution was to have code like this
in the constructor area of our Base cfc:
<CFParam Name="Session.Username" Default=""><!--- Ensure that the Username
exists. --->
<CFParam Name="Variables.ThisUsername" Default="#Session.Username#"><!--- Ensure
that the Username exists. --->
<CFIf
FileExists(ExpandPath("/Include/#Application.ApplicationName#SystemVariables.cfm"))>
<CFInclude
Template="/Include/#Application.ApplicationName#SystemVariables.cfm">
<CFElseIf Not
ListFindNoCase("EmployeeNomination,SCInvoiceAdministration,RecruitReport",
Application.ApplicationName)>
<CFSet TemplateRootPath = "">
<CFSet ThisPath = Trim(CGI.Path_Info)>
<CFLoop index="i" from="1" to="#ListLen(Trim(CGI.Path_Info),"/") - 1#">
<CFSet ThisPathPart = ListFirst(ThisPath,"/")>
<CFSet TemplateRootPath = ListAppend(TemplateRootPath,ThisPathPart,"/")>
<CFSet ThisPath = ListRest(ThisPath,"/")>
</CFLoop>
<CFSet TemplateRootPath = "/" & TemplateRootPath>
<CFIf FileExists(ExpandPath(TemplateRootPath & "/Application.cfm"))>
<CFInclude Template="#TemplateRootPath#/Application.cfm">
</CFIf>
</CFIf>
... All of this just to ensure that all of the nice variables that we've created
on the .cfm side of things will be available to all of our CFCs (or at least to
all of those that extend Base).
Okay, well, I'm not entirely keen on this way of doing things. I don't know, it
seems kludgey to me. So, I got the idea (maybe even from someone on this list, I
can't remember) that instead of including the stuff like that we should just
pass the contents of the variables scope into base when it's instantiated:
<CFIf NOT StructKeyExists(Session, "Base")>
<CFSet Session.Base = CreateObject("component",
"Include.CFC.Base").init(variables="#variables#")>
</CFIf>
... inside Base, the init function would look like this:
<cffunction name="init" returntype="any">
<cfscript>
// put the passed in variables into the local variables scope.
var myKey = "";
if(StructKeyExists(arguments, "variables")){
for(myKey in arguments.variables){
"variables.#myKey#" = arguments.variables[myKey];
}
}
return this;
</cfscript>
</cffunction>
I tried this in another of my CFCs (which did not extend Base) and it was
successful... until I needed a function that was in base... then it seemed
pointless, because I just ended up extending Base anyway.
The problem now (sorry for such a long post), is that when passing in the
contents of the variables scope like this, it works great for that CFC, but
other CFCs that extend it don't inherit those variables.
... and I just had a moment of clarity... just as I was writing that... it's
because when I instantiate Base and put it in the Session scope that's one
instance. But when I instantiate some other component which extends Base, it
gets it's own instance of Base (so to speak)... one that has not had the
variables passed into it.
*sigh*
Okay, so this post took a bit of a turn (sorry), but now I'm wondering, is there
a better way to accomplish what we're doing? Should we really be doing this in
the first place?
Thanks,
Chris
--
http://www.cjordan.us
_______________________________________________
Reply to DFWCFUG:
[email protected]
Subscribe/Unsubscribe:
http://lists1.safesecureweb.com/mailman/listinfo/list
List Archives:
http://www.mail-archive.com/list%40list.dfwcfug.org/
http://www.mail-archive.com/list%40dfwcfug.org/
DFWCFUG Sponsors:
www.instantspot.com/
www.teksystems.com/
