Chris,
I'd encourage you to read Adrian Moreno's blog at iknowkungfoo.com
<http://iknowkungfoo.com>. He's written a nice series of posts on
getting started with Mach-II. There are certainly other resources out
there, but Adrian is local and I know he reads the list (hi Adrian!),
and oh by the way he's no slouch where CF is concerned.
Good luck!
Eric
On 4/16/07, *Christopher Jordan* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Thanks Eric.
Eric Knipp wrote:
> I'm not sure of the state of your application and realize that
this may
> not be the best time for you to do major refactoring, but I would
> encourage you to evaluate Mach-II as a possible helper in getting
to a
> clear separation of concerns. A lot of what you're going to be
building
> yourself has been done before in Mach-II (and for that matter,
> Model-Glue, Coldbox, etc).
yeah, and the folks who wrote that stuff knew what the hell they
were doing...
as opposed to me. It's really been an up hill battle. My friend is very
procedural, and to be honest, I am too. But I'm *trying* to learn,
and utilize
OO principals, but I don't see him trying... well, not very hard anyway.
I'd like to look at a framework like those you've mentioned, but
wouldn't know
where to begin. I know the group has focused on one or two
frameworks before,
but stopped just about the time I started coming to meetings. Maybe
sometime the
subject will come around again, and I can pick it up then.
If I wasn't taking care of two client's I'd have more time to spend
educating
myself on a framework or two. Also, I think it would take a minor
miracle to get
anyone, but me excited about refactoring this project. :o(
Thanks again,
Chris
>
> Eric
>
> On 4/16/07, *Tom Woestman* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
> One other option - as far as I know other than memory usage
there is no
> significant negative to maintaining global vars in more than
one scope
> so you could put the variable in both variables and request
scope to
> keep your friend happy and maintain easy usability in CFCs.
>
> Hope this helps :)
>
> Tom
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> [mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] On Behalf Of
Christopher
> Jordan
> Sent: Monday, April 16, 2007 12:44 PM
> To: Dallas/Fort Worth ColdFusion User Group Mailing List
> Subject: Re: [DFW CFUG] CFCs: Passed in variables not inherited?
>
> Hi Tom,
>
> Yeah, that's basically what we're doing except we didn't
start off
> keeping the
> variables in the application or request scopes. :o( That
probably would
> have
> been the way to go. However knowing my friend, he'd complain
that he had
> to put
> 'application.' in front of all these variables. He likes that
he can
> just refer
> to them by name. *sigh*
>
> Thanks again, Tom! :o)
>
> Chris
>
> Tom Woestman wrote:
> > Hi Chris,
> >
> > We put variables 'global' variables in either the request or
> application
> > scope so they are available to all CF code scopes be it a
single CF
> > template or a CFC. We also put all variable declarations
of this
> type
> > in a single file that is included by the application.cfm
or a central
> > controller file for our application. This tends to keep the
> > application.cfm much cleaner.
> >
> > We also have different settings for these variables based
on the tier
> > the application is running on. For example, in our dev
tier we will
> > output error emails to just the developers working on the
> application,
> > but in production error emails also go to our systems
support team.
> >
> > I hope you find these useful,
> > Tom
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>
> > [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>>] On Behalf Of
> Christopher
> > Jordan
> > Sent: Monday, April 16, 2007 11:09 AM
> > To: Dallas/Fort Worth ColdFusion User Group Mailing List
> > Subject: [DFW CFUG] CFCs: Passed in variables not inherited?
> >
> > 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#SystemVaria
>
> > bles.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] <mailto:[email protected]>
<mailto:[email protected] <mailto:[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/
> < http://www.mail-archive.com/list%40dfwcfug.org/>
> DFWCFUG Sponsors:
> www.instantspot.com/ <http://www.instantspot.com/>
<http://www.instantspot.com/ <http://www.instantspot.com/>>
> www.teksystems.com/ <http://www.teksystems.com/>
<http://www.teksystems.com/>
>
>
> _______________________________________________
> Reply to DFWCFUG:
> [email protected] <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>>
> Subscribe/Unsubscribe:
> http://lists1.safesecureweb.com/mailman/listinfo/list
> <http://lists1.safesecureweb.com/mailman/listinfo/list
<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/
> <http://www.mail-archive.com/list%40dfwcfug.org/>
> DFWCFUG Sponsors:
> www.instantspot.com/ <http://www.instantspot.com/>
<http://www.instantspot.com/>
> www.teksystems.com/ <http://www.teksystems.com/> <
http://www.teksystems.com/>
>
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Reply to DFWCFUG:
> [email protected] <mailto:[email protected]>
> Subscribe/Unsubscribe:
> http://lists1.safesecureweb.com/mailman/listinfo/list
<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/ <http://www.instantspot.com/>
> www.teksystems.com/ <http://www.teksystems.com/>
--
http://www.cjordan.us
_______________________________________________
Reply to DFWCFUG:
[email protected] <mailto:[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/ <http://www.instantspot.com/>
www.teksystems.com/ <http://www.teksystems.com/>
------------------------------------------------------------------------
_______________________________________________
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/
