This is another 'what are you doing' and 'does it sound
right' topics. I'm
cleaning up some CFCs here and the programmer put some
CFLOCATION tags
inside the CFC. Anyone else do this? Anyone see a problem
with it?
Personally, I'm not happy about it as it breaks
encapsulation and makes
I use this for CFC's that are meant to be the action of forms. This is
actually shown in the documentation.
FORM.cfm
form action=processing.cfc ...
input type=hidden name=method value=methodName
/form
PROCESSING.cfc
cfcomponent
cffunction name=methodName ...
Do everything I want to
For some reason posting to a cfc like that doesn't feel right to me. But
that's just my preference.
- Calvin
-Original Message-
From: Ian Skinner [mailto:[EMAIL PROTECTED]
Sent: Friday, March 04, 2005 12:12 PM
To: CF-Talk
Subject: RE: CFLOCATION inside CFCs
I use this for CFC's
But in this case your accessing a CFC directly (where the method is
access=remote).
I use this for CFC's that are meant to be the action of forms. This is
actually shown in the documentation.
FORM.cfm
form action=processing.cfc ...
input type=hidden name=method value=methodName
/form
Sacramento, CA
C code. C code run. Run code run. Please!
- Cynthia Dunning
-Original Message-
From: Michael Dinowitz [mailto:[EMAIL PROTECTED]
Sent: Friday, March 04, 2005 9:20 AM
To: CF-Talk
Subject: RE: CFLOCATION inside CFCs
But in this case your accessing a CFC
Subject: RE: CFLOCATION inside CFCs
I use this for CFC's that are meant to be the action of forms. This is
actually shown in the documentation.
FORM.cfm
form action=processing.cfc ...
input type=hidden name=method value=methodName
/form
PROCESSING.cfc
cfcomponent
cffunction name=methodName
[mailto:[EMAIL PROTECTED]
Sent: Friday, March 04, 2005 9:32 AM
To: CF-Talk
Subject: RE: CFLOCATION inside CFCs
I prefer to use a .cfm for my form action that interacts with the cfc.
Keeps the cfc a black box. Then the .cfm decides what to do if the cfc
action succeeds
That is exactly true, and that is the only time *I* would
consider using a cflocation in a CFC. I kind of feel
it's between my UI layer and my Logic layer.
I've only just started on figuring out OOD/OOA so I'm
working from the inside out. When I'm better and doing OO
at all levels, then I
From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
cfparam name=attributes.objectid type=numeric default=0
cfif objectid... do stuff .../cfif
In my case the attributes scope is a combination of form and
url variables... And at a first glance this looks really good
because it's nice and
I can't see that being a problem if you are incorporating proper
serverside form validation. Serverside you should be checking all
validation rules, does it exist, is it the required datatype, the
required length...
On Fri, 4 Mar 2005 12:42:38 -0500, S. Isaac Dealey [EMAIL PROTECTED] wrote:
On Fri, 4 Mar 2005 11:55:53 -0500, Michael Dinowitz
[EMAIL PROTECTED] wrote:
This is another 'what are you doing' and 'does it sound right' topics. I'm
cleaning up some CFCs here and the programmer put some CFLOCATION tags
inside the CFC. Anyone else do this? Anyone see a problem with it?
The example I have is a redirect embedded inside business logic. Call a
page, call the object, do a bunch of stuff, have the object throw you
somewhere else. Not dedicated, not validation, just a part of the code.
I'm going to pull it out and put it into it's own method with solid
validation and
On Fri, 4 Mar 2005 13:40:15 -0500, Michael Dinowitz
[EMAIL PROTECTED] wrote:
The example I have is a redirect embedded inside business logic. Call a
page, call the object, do a bunch of stuff, have the object throw you
somewhere else. Not dedicated, not validation, just a part of the code.
Well the comment is much less about form variables (which would be
validated in other ways) than it is about url variables. If a page is
going to use url variables at all, there is always the risk of it
producing a CF error if a user provides a url variable that's
inappropriate. Some of this can
From: S. Isaac Dealey [mailto:[EMAIL PROTECTED]
cfparam name=attributes.objectid type=numeric
default=0
cfif objectid... do stuff .../cfif
In my case the attributes scope is a combination of form
and
url variables... And at a first glance this looks really
good
because it's nice and
EXACTLY how I am now coding my apps.
So far I have not seen any mention of how this helps allow for code reuse
and how much easier for someday when you want to talk to that CFC via a
Flash form or web service.
-Original Message-
From: Sean Corfield [mailto:[EMAIL PROTECTED]
Sounds
My only concern at the moment is taking a freekin huge application written
in a multitude of styles and
1. remove excess code
2. clean up logic
3. allow all sites using the code to work well
4. run fast
Code reuse and external calls are after cleanup.
One thing I've had to do is move all queries
17 matches
Mail list logo
