RE: Help with CFC and recursion?
Thanks for the tips Sean, Raymond, et al
I had tried using the VAR bit before, but the code choked. I didn't even
think of doing it in CFSET tags. (And, I learned that a CFTRY tag is
interpreted as executable code.) The function is working now.
As for my use of the CFPROPERTY tags, I know they are kinda useless in the
manner I'm using them, EXCEPT for documentation. If you pull up the CFC in
a browser directly (i.e. http://myserver/mydir/mycfc.cfc), then you get a
very nicely formated page documenting everything there is to know about the
component. If you don't use the CFPROPERTY tag, then the properties section
is empty. We are intending to print these screens to document our classes,
so having the properties listed is an added bonus. Also, some of our
components will likely become web services in the near future - we're still
getting the core code into place so we can proceed with the presentation
layer.
Thanks for the input on recursion, and some tips on CFProperty - on which I
have not been able to find any great details.
Shawn
-Original Message-
From: Sean A Corfield [mailto:[EMAIL PROTECTED]
Sent: Monday, May 26, 2003 8:07 PM
To: CF-Talk
Subject: Re: Help with CFC and recursion?
On Monday, May 26, 2003, at 17:41 US/Pacific, Shawn Grover wrote:
> I've tried a number of combinations for the code, and always seem to
> get a
> similar result.
You need to use 'var' to declare your variables local - otherwise they
are just instance variables and get overwritten by each recursive call.
>
>
Why bother with this if it isn't a Web Service? cfproperty has no
useful purpose except for type-checking Web Service returns.
>
> this.Category = createObject("component",
> "caa.intranet.cfc.data.category");
> this.Category.Clear();
> this.List = this.Category.List();
>
>
>
>
>
>
>qRoot.Category_Name)>
>
>
>
>
>
>output="no">
>
>required="Yes">
>
> sChild = "[#JSStringFormat(Arguments.CategoryName)#,
> 'javascript:node_clicked(#Arguments.CategoryID#);', null";
>
> qChildren = getChildren(Arguments.CategoryID);
> for (x=1; x lte qChildren.RecordCount; x=x+1) {
> sChild = sChild &
> AddNode(qChildren.Category_ID[x], qChildren.Category_Name[x]);
> }
>
> sChild = sChild & " ], ";
>
>
>
>
>
>
>
>
>
>
You can delete this line ^^^
>
> Select *
> From qTemp
> Where Parent_ID = #Arguments.ParentID#;
>
>
>
>
>
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Signup for the Fusion Authority news alert and keep up with the latest news in
ColdFusion and related topics.
http://www.fusionauthority.com/signup.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Help with CFC and recursion?
On Tuesday, May 27, 2003, at 13:14 US/Pacific, Shawn Grover wrote: > As for my use of the CFPROPERTY tags, I know they are kinda useless in > the > manner I'm using them, EXCEPT for documentation. And of course it all depends on whether you want to use public data members - "this" scope - which you might want to document with cfproperty or non-public data members - unnamed scope - which you would not want to document with cfproperty (since the documentation is of the public interface). Are other folks relying on cfproperty for auto-documenting public data members? How do you deal with keeping the cfproperty tags in sync with what you actually do with "this" scope variables? Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Help with CFC and recursion?
We're declaring a Clear function which initializes the THIS properties to a valid, known state. Our procedure is to ensure the clear function matches the CFPROPERTY declarations, and we call the Clear function when the CFC is initialized. -Original Message- From: Sean A Corfield [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 27, 2003 4:10 PM To: CF-Talk Subject: Re: Help with CFC and recursion? Are other folks relying on cfproperty for auto-documenting public data members? How do you deal with keeping the cfproperty tags in sync with what you actually do with "this" scope variables? Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Help with CFC and recursion?
On Tuesday, May 27, 2003, at 16:20 US/Pacific, Shawn Grover wrote: > We're declaring a Clear function which initializes the THIS properties > to a > valid, known state. Our procedure is to ensure the clear function > matches > the CFPROPERTY declarations, and we call the Clear function when the > CFC is > initialized. And what's to stop some arbitrary method just setting this.foo to some value? (or, worse, some client code that instantiates a CFC and then sets the public data) foo.cfc: ... bogus.cfm: Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Host with the leader in ColdFusion hosting. Voted #1 ColdFusion host by CF Developers. Offering shared and dedicated hosting options. www.cfxhosting.com/default.cfm?redirect=10481 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
RE: Help with CFC and recursion?
This falls under the "black box" concept, in that the component isn't
supposed to know about the environement is getting used in. We don't care
if some arbitrary code changes the properties. However, we do care about
having valid data before it is placed into the database. So, our components
(data access components at least) have an isValid() function which is
public, and is also called internally when a save is done.
When I first started exploring components in detail (all of 3 weeks ago),
this was the first issue we ran into - you can't really type cast your
properties, then enforce that type casting (at least not when using a CFC as
a component - I understand this may be different when used as a web
service). We were initially going to create get and set methods for member
variables (not in the THIS scope), but quickly realized this was
meaningless, because I was free to set variables on the object willy-nilly.
For example, a component might have two official properties - say "x" and
"y". I can freely create my own properties by assigning a value to them
(like javascript)... :
oPos = createObject("component", "myposition");
oPos.x = 5;
oPos.y = 6;
oPos.z = 15;//This is not an officially supported property
oPos.MyOwnProperty = "Hi ya Bob"; //another "unofficial" property
If you do a cfdump of the oPos object, it DOES reflect the two additional
properties, even though they were not defined in the CFC. So, doing get's
and set's to enforce data type becomes meaningless - instead of saying
oObj.getProperty(); a user could do oObj.Property = 1;, and x =
oObj.Property;, bypassing the functions. We decided it was easiest to
simply validate the properties before saves, and allow the calling code to
call the isValid method as well.
k, I've rambled on long enough... hope this helps someone out there.
Shawn
-Original Message-
From: Sean A Corfield [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 27, 2003 5:30 PM
To: CF-Talk
Subject: Re: Help with CFC and recursion?
On Tuesday, May 27, 2003, at 16:20 US/Pacific, Shawn Grover wrote:
> We're declaring a Clear function which initializes the THIS properties
> to a
> valid, known state. Our procedure is to ensure the clear function
> matches
> the CFPROPERTY declarations, and we call the Clear function when the
> CFC is
> initialized.
And what's to stop some arbitrary method just setting this.foo to some
value? (or, worse, some client code that instantiates a CFC and then
sets the public data)
foo.cfc:
...
bogus.cfm:
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Get the mailserver that powers this list at
http://www.coolfusion.com
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Re: Help with CFC and recursion?
On Tuesday, May 27, 2003, at 17:30 US/Pacific, Shawn Grover wrote:
> We were initially going to create get and set methods for member
> variables (not in the THIS scope), but quickly realized this was
> meaningless, because I was free to set variables on the object
> willy-nilly.
But the variables you set on the object are in "this" scope which you
can ignore inside the CFC and only use the unnamed scope.
>
> oPos = createObject("component", "myposition");
> oPos.x = 5;
> oPos.y = 6;
> oPos.z = 15;//This is not an officially supported property
> oPos.MyOwnProperty = "Hi ya Bob"; //another "unofficial" property
>
>
> If you do a cfdump of the oPos object, it DOES reflect the two
> additional
> properties, even though they were not defined in the CFC.
Correct. But cfdump does not show any non-public data that the CFC has
set itself, which is the key point.
> So, doing get's
> and set's to enforce data type becomes meaningless - instead of saying
> oObj.getProperty(); a user could do oObj.Property = 1;, and x =
> oObj.Property;, bypassing the functions.
Consider this:
foo.cfc:
rogue.cfc:
#foo.getFoo()#
#foo.getFoo()#
You will see that using the unnamed scope instead of "this" scope
protects your data - the foo.foo = "goodbye" has no effect on 'foo'
inside the CFC (because it sets 'this.foo' instead).
A common idiom folks seem to have adopted is actually this:
foo.cfc:
This creates a non-public (and therefore protected) instance variable
(called 'instance') which acts like a scope for all your instance data
- and also allows your setXxx() method to use the same name for its
argument as for the instance variable itself (which is not possible
using the unnamed scope).
In theory, you ought to be able to use "variables" scope instead of the
"instance" 'scope' shown above but, right now, there's a bug in CFMX
which makes "variables" scope break in CFCs (which will get fixed in
due course).
Hope that helps explain how to use get/set to encapsulate your data and
avoid 'malicious' code outside the object from messing with it.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Get the mailserver that powers this list at
http://www.coolfusion.com
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
