On Sun, Oct 14, 2012 at 7:27 PM, Azadi Saryev azadi.sar...@gmail.comwrote:
If it is only applicationname that you need to be unique, then you
could just use a hash of template path as app name, or some variation
of the below:
this.name = hash(getCurrenttTmplatePath());
I second this
cf-talk@houseoffusion.com
Message-ID:
cafczd6eray5dujyqz9pwcxqndfg543tqihedxuykvvvmo4e...@mail.gmail.com
Subject: Re: Best practice question for Application.cfc
References: 15d47c6$67f60c41$750c1d46$@com
Date: Tue, 16 Oct 2012 12:41:22 +0900
Precedence: bulk
Reply-To: cf-talk@houseoffusion.com
From
: Re: Best practice question for Application.cfc
References: 4f9f30b3$2f548fd9$34618e3a$@com
Date: Mon, 15 Oct 2012 08:27:46 +0900
Precedence: bulk
Reply-To: cf-talk@houseoffusion.com
From: Azadi Saryev azadi.sar...@gmail.com
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content
Hi Folks,
I have a question regarding the best way to handle loading an API for the
CMS side of our application.
In this case, the API I am talking about not meant for remote calls but
instead is meant to be for web developers creating themes and features for
a web site who need to be able to
It sounds like you're dealing with a singleton, so instantiating it
onApplicationStart() and placing it into the application scope would be
perfectly reasonable. I let ColdSpring manage my singletons for me, but
it's the same basic principle: Instantiate ColdSpring onApplicationStart(),
and it
:
CAFcZD6dP9NYjRtW6QVzen=penxrnowx4hw-6brii9jssp0h...@mail.gmail.com
Subject: Re: Best practice question for Application.cfc
References: 4f9f30b3$2f548fd9$34618e3a$@com
Date: Mon, 15 Oct 2012 08:27:46 +0900
Precedence: bulk
Reply-To: cf-talk@houseoffusion.com
From: Azadi Saryev azadi.sar
If it is only applicationname that you need to be unique, then you
could just use a hash of template path as app name, or some variation
of the below:
this.name = hash(getCurrenttTmplatePath());
Azadi
On Sat, Oct 13, 2012 at 10:47 PM, Nick Gleason n.glea...@citysoft.com wrote:
Hi Folks,
.safesecureweb.com with SMTP;
Sat, 13 Oct 2012 14:12:49 -0400
To: cf-talk cf-talk@houseoffusion.com
Message-ID:
CAOnEp2f+=czlr6qqqsjymn6lvnqy0srlow5ts+ks8nv5+a6...@mail.gmail.com
Subject: Re: Best practice question for Application.cfc
References:
CACi=xszchjy1aa1pzuhnjw5qktbat800vd+sasfjpmvugv9
Hi Folks,
We're moving from application.cfm to application.cfc and I had a question
regarding best practices.
We re-use our base code and in the past, we have used a settings page that
is external from the base code and unique per client to set the
applicationname variable (and other
We're moving from application.cfm to application.cfc and I had a question
regarding best practices.
We re-use our base code and in the past, we have used a settings page that
is external from the base code and unique per client to set the
applicationname variable (and other variables). This
Which ever way you do it, somewhere or other you have to have a file
that's unique to this site, or have a settings record in a database or
some such. Does it REALLY make much difference if it's a site-specific
Application.cfc or a site-specific Settings.xml file or a site-specific
Settings
Hello,
I'm setting up a new environment and I would like to have the ability,
through a web UI to copy objects from our production database (separate
server) to a development/debugging database (separate server). My question
is not about how to implement this but rather whether this is bad
Putting production data source connections on the development server
is a practice you should avoid. I cringe whenever I see developers do
this.
Having the development DSN on the production server is less risky.
Another path would be having the two databases linked at the database
level and use
just take a copy of the live database and remove all sensitive data from it.
either remove all data and replace with demo data, or just run a query that
replaces the sensitive data with something else.
On Sat, Jan 28, 2012 at 10:15 PM, Mike Chabot mcha...@gmail.com wrote:
Putting production
-Original Message-
From: Brook Davies [mailto:cft...@logiforms.com]
Sent: Saturday, January 28, 2012 4:02 PM
To: cf-talk
Subject: Best Practice question about database access between Dev and
Production Servers
Hello,
I'm setting up a new environment and I would like to have the ability
On Mon, Mar 7, 2011 at 10:56 AM, Nathan Strutz str...@gmail.com wrote:
If you have a lot of arguments, one way to refactor that is to make a
component that encompasses those arguments - essentially a bean, maybe a
couple of beans if the arguments are unrelated. In your first public method,
Hello,
Just a quick Best Practices question. I have a CFC, I call a method and
pass a slew of arguments to it. Internally it calls a private method using
argumentCollection=arguments. My question is, should I repeat the argument
definitions on the private method?
The arguments are
Presumably your private method is being called by multiple methods. It is
definitely much better - at least in terms of documentation - to have those
arguments clearly defined. :-)
If, however, multiple methods do not call that private method, then there is
no need for the private method to
If, however, multiple methods do not call that private method, then there is
no need for the private method to exist.
I wouldn't go as far as that. Private methods like this can serve the
same purpose as functions or subroutines anywhere else - to limit the
amount of code in the main method,
On Mon, Mar 7, 2011 at 11:21 AM, Dave Watts wrote:
If, however, multiple methods do not call that private method, then there
is
no need for the private method to exist.
I wouldn't go as far as that. Private methods like this can serve the
same purpose as functions or subroutines
If you have a lot of arguments, one way to refactor that is to make a
component that encompasses those arguments - essentially a bean, maybe a
couple of beans if the arguments are unrelated. In your first public method,
instantiate that bean with the arguments, then just pass that bean around.
On Mon, Mar 7, 2011 at 9:24 AM, Matt Quackenbush quackfu...@gmail.com wrote:
That's the beauty of refactoring, though. Unless you need to, don't. And
if no other method is calling it (or expected to call it), then it is not
needed. If it becomes needed, refactor and add it in. :-)
I
I generally agree with this notion but I think it starts to fall apart
with more complex methods. You might have a whole routine that only
gets called one place but is complex enough that there are benefits to
breaking it up into multiple methods that have single concerns. Doing
so makes it
On Mon, Mar 7, 2011 at 11:57 AM, Judah McAuley wrote:
On Mon, Mar 7, 2011 at 9:24 AM, Matt Quackenbush wrote:
That's the beauty of refactoring, though. Unless you need to, don't.
And
if no other method is calling it (or expected to call it), then it is not
needed. If it becomes
Is there a way to capture a row? For example, if you know the value of a cell,
can you do some structure or array search that would return the row? I know we
can use query of queries to find it, but I wonder if you know another way using
array or structure functions.
Johnny
-Original
: Best practice question?
Is there a way to capture a row? For example, if you know the value of a
cell, can you do some structure or array search that would return the row?
I know we can use query of queries to find it, but I wonder if you know
another way using array or structure functions.
Johnny
][qry.currentrow]
/cfloop
/cfif
/cfloop
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: 29 March 2005 13:56
To: CF-Talk
Subject: Re: Best practice question?
Is there a way to capture a row? For example, if you know the value of a
cell, can you do some structure
FORM and URL are tied to user
submitted fields, while CGI and Cookie are usually not so.
- Calvin
-Original Message-
From: Joe Rinehart [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 7:28 PM
To: CF-Talk
Subject: Re: Best practice question?
I'm half-tempted to expand
That may be so, but in my thoughts, FORM and URL are implicitly similar in
functionality, however CGI and Cookie are different.
- Calvin
-Original Message-
From: Joe Rinehart [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 29, 2005 2:06 PM
To: CF-Talk
Subject: Re: Best practice question
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 29, 2005 7:56 AM
To: CF-Talk
Subject: Re: Best practice question?
Is there a way to capture a row? For example, if you know the value of a
cell, can you do some structure or array search that would
Subject: Re: Best practice question?
But it IS a broad application-development question!
You can't decide *not* to scope a variable until you know *why* you
would scope one to begin with. You can't decide to rely on CF's
default scoping capabilities successfully until you know all the
implications
I just tried ArraySum(queryname[fieldname]) and it works, but when I tried to
get the array queryname[fieldname], all I got is the value of the first row.
I use cfdump var=#queryname[fieldname]#. I used cfset something =
queryname[fieldname]/. None of them comes out as an array.
Johnny
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 10:07 AM
To: CF-Talk
Subject: Re: Best practice question?
I just tried ArraySum(queryname[fieldname]) and it works, but when I
tried to get the array queryname[fieldname], all I got
Thanks, Jim. This helps a lot.
Johnny
-Original Message-
It's definitely at least a little flakey (which is why I stressed testing
this stuff out first). It seems to only be an array on a direct access, not
an assignment. So the following all work fine:
+)
On Sun, 27 Mar 2005 23:10:09 -0500, Justin D. Scott [EMAIL PROTECTED] wrote:
That's why I like the way FuseBox handles input. So much so that I use it
even outside my FuseBox apps. It takes all of the FORM and URL variables
and moves them to the ATTRIBUTES scope if it doesn't already exist.
I'm half-tempted to expand Model-Glue to treat CGI in the same manner.
It'd be nice to have one big untrustable scope for validation and
security purposes. However, thinking along that line, I should also
include Cookie, but that's getting into four layers of priority, which
could be confusing.
I'm not sure that would be a good idea, both FORM and URL are tied to user
submitted fields, while CGI and Cookie are usually not so.
- Calvin
-Original Message-
From: Joe Rinehart [mailto:[EMAIL PROTECTED]
Sent: Monday, March 28, 2005 7:28 PM
To: CF-Talk
Subject: Re: Best practice
26, 2005 5:34 PM
To: CF-Talk
Subject: RE: Best practice question?
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 26, 2005 12:33 AM
To: CF-Talk
Subject: Best practice question?
Is it better to do this:
cfoutput query=GetCourses
#Dept_ID
I believe that scoping is important and removed ambiguity
Right, however, in some circumstances, ambiguity may be a useful feature.
For instance, not specifying the form or url scope for a variable can
make a template work both as a form action or as an href called template
with parameters
declare which scope I want to have
precedence while I'm at it.
- Calvin
-Original Message-
From: Claude Schneegans [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 27, 2005 9:23 AM
To: CF-Talk
Subject: Re: Best practice question?
I believe that scoping is important and removed ambiguity
looks like scoping AND no scoping are desirable depending on the application.
Kinda goes back to my registering to purchase a product question. It's an
application-specific question, not a broad application development question.
Will
one may note that this is copied from
fusebox's functionality
Yes, but this is one of the things I hate the most in FB: using the attributes
structure, so that one never knows if a template is used as a custom tag or not.
--
___
REUSE CODE! Use custom
looks like scoping AND no scoping are desirable depending on the
application.
Exact, that's one of the advantages of using a weakly or dynimically
typed language.
Since both scoping and no scoping (or default scoping) are features of
CF, rules like never do or always do
can only make the
But it IS a broad application-development question!
You can't decide *not* to scope a variable until you know *why* you
would scope one to begin with. You can't decide to rely on CF's
default scoping capabilities successfully until you know all the
implications of them. It is a broad app-dev
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 26, 2005 12:33 AM
To: CF-Talk
Subject: Best practice question?
Is it better to do this:
cfoutput query=GetCourses
#Dept_ID# #CorName# #CorLevel#br
/cfoutput
or this:
cfoutput
latter have to work on that page.
I would opine that scoping is a best practice.
- Calvin
-Original Message-
From: Jim Davis [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 26, 2005 5:34 PM
To: CF-Talk
Subject: RE: Best practice question?
When the examples are this simple it doesn't
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 27, 2005 3:41 PM
To: CF-Talk
Subject: Re: Best practice question?
In CFC, I always do this:
cffunction name = something
cfargument name=some required=true type=string/
cfset var few
In CFC, I always do this:
cffunction name = something
cfargument name=some required=true type=string/
cfset var few = arguments.some/ cfset few = 10/ /cffunction
If we should always scope our variables. Should I do this?
cfset var variables.few = arguments.some/ cfset
variables.few
On Sun, 27 Mar 2005 15:06:43 -0500, Andrew Tyrone [EMAIL PROTECTED] wrote:
I might be crazy, but I seem to remember, at least in CF 4.x versions, that
if you scoped a query column within a cfoutput, it would only output the
data in the first row of the query, not the current row, no matter
You had to use the query name in cfloop but not in cfoutput.
That's the only rule there was... at least that I recall...
so this worked:
cfoutput query=qryName#colName#/cfoutput
And this worked:
cfloop query=qryName#qryName.colName#/cfloop
But this would only output the first row for every
isnt it just better to use
cfloop query=
/cfloop
and only output when you need to output?
or wrap the cfoutput around the whole thing?
just wondering... im a big fan of
cfloop from = 1 to = #myQuery.recordCount# id = i
/cloop
and then make myself access everything with
On Sun, 27 Mar 2005 15:06:43 -0500, Andrew Tyrone [EMAIL PROTECTED]
wrote:
I might be crazy, but I seem to remember, at least in CF 4.x versions,
that
if you scoped a query column within a cfoutput, it would only output the
data in the first row of the query, not the current row, no
On Sun, 27 Mar 2005 17:39:35 -0500, Jim Davis
[EMAIL PROTECTED] wrote:
On Sun, 27 Mar 2005 15:06:43 -0500, Andrew Tyrone [EMAIL PROTECTED]
wrote:
I might be crazy, but I seem to remember, at least in CF 4.x versions,
that
if you scoped a query column within a cfoutput, it would only
-Original Message-
From: Jared Rypka-Hauer - CMG, LLC [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 27, 2005 6:09 PM
To: CF-Talk
Subject: Re: Best practice question?
The odd thing is with queries should you use indexed notation you get a
different value. While the value
Explicit scoping _IS_always_ the best idea, unless you have a
compelling rationale to break with the best practice.
and vice versa ;-)
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.cfm
(Please send any
practice question?
The odd thing is with queries should you use indexed notation you get a
different value. While the value of queryname.fieldname is the value
of
the first row the value of queryname[fieldname] is actually a
reference
the column - essentially a one dimensional array
isnt it just better to use
cfloop query=
/cfloop
and only output when you need to output?
Then you loose the GROUP facility in the CFOUTPUT tag.
If I remember well, the CFLOOP tag was introduced in version 3 or so to add
facilities than the CFOUTPUT tag had not. But it can't replace it
What surprise me is that this would not work at all, not even the value of the
first row. It actually throws an error:
cfoutput#colName#/cfoutput
I thought that query result variables do not require prefix if in a cfoutput
loop, and query result variable is actually the first scope in the
I thought that query result variables do not require prefix
if in a cfoutput loop, and query result variable is
actually the first scope in the order of evaluation that
coldfusion would look for. I guess cfoutput/cfoutput
alone is not a loop. I guess you need the query attribute to
Right, however, in some circumstances, ambiguity
may be a useful feature. For instance, not
specifying the form or url scope for a variable
can make a template work both as a form action or
as an href called template with parameters passed
in the url.
That's why I like the way FuseBox
This sounds great, but isn't the args variable has its own scope too? It is
variables scope, isn't it? Since it declares locally in the function, I am not
sure if its scope is variables, but it has a scope of something. So if you
have scope everything, you would have to do
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 27, 2005 10:43 PM
To: CF-Talk
Subject: Re: Best practice question?
This sounds great, but isn't the args variable has its own scope too? It
is variables scope, isn't it? Since it declares locally
Johnny,
Technically, yeah, that's exactly right.
If you want to see all your scopes and all their contents, try this:
cfdump var=#getPageContext().getBuiltinScopes()# /
That will dump every built-in scope, or those available to any page,
special tag scopes notwithstanding, including:
cffile
cgi
-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 27, 2005 10:43 PM
To: CF-Talk
Subject: Re: Best practice question?
This sounds great, but isn't the args variable has its own scope too? It
is variables scope, isn't it? Since it declares locally in the function,
I am
There may be a performance penalty but I've never heard of it. but
I've always scoped everything in sight. I just ran into an
application I was asked to review where the developer scoped
*nothing*. Thats obviously a different situation but I think not
scoping *any* var is just a lesser form of
-Original Message-
From: Johnny Le [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 26, 2005 12:33 AM
To: CF-Talk
Subject: Best practice question?
Is it better to do this:
cfoutput query=GetCourses
#Dept_ID# #CorName# #CorLevel#br
/cfoutput
or this:
cfoutput query
Is it better to do this:
cfoutput query=GetCourses
#Dept_ID# #CorName# #CorLevel#br
/cfoutput
or this:
cfoutput query=GetCourses
#GetCourses.Dept_ID# #GetCourses.CorName# #GetCourses.CorLevel#br
/cfoutput
I know that you should prefix your variables, but this seems to be
What about this case:
cfoutput query=getCourses
cfset dept_id = 4 /
#dept_id#
/cfoutput
What is that going to output? If you'd scoped it (either with the
query name or the variables scope, depending on which you intended to
output), then it would be clear what your intent was. So there's a
68 matches
Mail list logo
