Re: So many problems with CFC scopes...

[Sean A Corfield]

On Thursday, Sep 26, 2002, at 11:32 US/Pacific, Benoit Hediard wrote:
 I was wondering if anyone know when MM is going to fix all the issues
 related to CFC scopes.

Red Sky is coming soon. I can't say whether it will fix all your 
problems - due to the NDA (although some of the issues you mention are 
fixed according to some of the information various folks have been 
allowed to make public!).

Apply to join the Red Sky beta:
http://www.macromedia.com/go/cfmxbeta

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=subscribeforumid=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: So many problems with CFC scopes...

[Raymond Camden]

I _finally_ got off my lazy you know what and posted my CFC preso from
CFUN. I was given specific permission to mention certain fixes. Download
the PPT to see. I didn't see your original post, but somethings
mentioned in the ppt:

Issue with Variables scope not really being Variables in the cfc -
fixed.
The infamous page context bug - fixed.

And more. Download the PPT to see.

In general, I am very, very pleased with CFCs in RedSky. Add the fact
that it seems to run about a hunded times faster, and this is going to
be an amazing release. (Ok, 100x may be a bit high. ;)


===
Raymond Camden, ColdFusion Jedi Master for Mindseye, Inc
(www.mindseye.com)
Member of Team Macromedia (http://www.macromedia.com/go/teammacromedia)

Email: [EMAIL PROTECTED]
Blog : www.camdenfamily.com/morpheus/blog
Yahoo IM : morpheus

My ally is the Force, and a powerful ally it is. - Yoda 

 -Original Message-
 From: Sean A Corfield [mailto:[EMAIL PROTECTED] 
 Sent: Tuesday, July 15, 2003 4:08 PM
 To: CF-Talk
 Subject: Re: So many problems with CFC scopes...
 
 
 On Thursday, Sep 26, 2002, at 11:32 US/Pacific, Benoit Hediard wrote:
  I was wondering if anyone know when MM is going to fix all 
 the issues 
  related to CFC scopes.
 
 Red Sky is coming soon. I can't say whether it will fix all your 
 problems - due to the NDA (although some of the issues you 
 mention are 
 fixed according to some of the information various folks have been 
 allowed to make public!).
 
 Apply to join the Red Sky beta:
   http://www.macromedia.com/go/cfmxbeta
 
 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=subscribeforumid=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: So many problems with CFC scopes...

[Benoit Hediard]

Sorry, I come back to the original thread problem : CFC scopes.
Here are some more details one CFCs scopes and UDFs.

When you excecute a CFMODULE, the only scopes still available in the
CFMODULE script are 'attributes' + request/url/form, so you have to
re-include UDF Lib.
Which means that UDF Lib scope (from the calling script) is not available in
a script executed by CFMODULE.

When you execute a CFC (or a custom tags), it should be the same.
The only scopes still available in the CFC script are 'arguments' +
request/url/form, but there is a problem : UDF Lib scope from the calling
script is still available in the CFC (???).
This is not logical.
CFC should not be able to access UDF Lib scope from the calling script, it
should behave like the CFMODULE.
UDF have by default the no prefix scope, so I thought they would behave
like no prefix variables.
(and if I want a UDF function during all my request, then I put it in the
request scope)

So for me, this is a bug (a non-consistent behaviour).
Don't you think?

Benoit Hediard
www.benorama.com

-Message d'origine-
De : Raymond Camden [mailto:[EMAIL PROTECTED]]
Envoyé : dimanche 29 septembre 2002 21:06
À : CF-Talk
Objet : RE: So many problems with CFC scopes...



 For what reason? I've jumped in mid-thread here, but I'm
 really keen to get
 some good nitty-gritty low-down on the pros/cons/appropriate
 contexts for
 custom tags/UDFs/CFCs.

 I've had access to CF5 for a while, but most of my clients
 have been stuck
 on CF4.5 hosts, so I've not really got into the habit of
 UDFs. Now MX and
 CFCs are here, I feel I should dive into the whole lot
 knowing the practical
 differences and arguments for each method.

 You mentioned typing the extra reference for CFCs (i.e.
 myCFC.isEmail(...)
 as opposed to isEmail() for a UDF). Beyond that - which is
 obviously down to
 the kind of personal preference that's not worth debating -
 why would a CFC
 set of methods as opposed to a UDF library be not bad per
 se, just maybe
 not appropriate? What's the not appropriate bit, in
 performance/architecture terms, not personal
 preference/coding style terms?


Dave mentioned a collection of UDFs called Math that would serve as a
library. On a _completely_
personal level (ie, not performance, security, etc), I tend to think the
methods of a CFC should be
more tightly coupled - ie, have more of a reason then being together
than just being mathematical.

As a purely personal preference - that is why I wouldn't think it's
appropriate. Yes, I know it's a very
wishy-washy response - but as I said, it's a personal feeling. Also,
with CFCs being such a new beast,
what makes sense now and what makes sense 3 years from now will most
likely be somewhat different.

===
Raymond Camden, ColdFusion Jedi Master for Hire

Email: [EMAIL PROTECTED]
Yahoo IM : morpheus

My ally is the Force, and a powerful ally it is. - Yoda



__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Benoit Hediard]

I agree with you Raymond.
But it is true that is more personal preference/coding style terms than
performance/architecture terms.

This are my personal rules :
CUSTOM TAGS (ColdFusion Taglibs)
- custom tags encapsulates presentation logic they always output content
(usually HTML),
- custom tags usually do not call the model or controller layer,
- custom tags are only used by the presentation layer (page or pagelet
scripts).
 They are used for presentation logic encapsulation.

USER DEFINED FUNCTIONS (UDF)
- user defined functions encapsulate generic logic and rarely output content
(except for string formatting purposes),
- user defined functions do not call the model or controller layer,
- user defined functions are used in any layer (view, controller or model).
 They are used generic logic/function encapsulation.

COLDFUSION COMPONENTS (CFC)
- components encapsulate business/data access application logic and never
output content,
- components are called by the view layer only to read data,
- components are called by the controller layer to create/update/delete
data.
 They are used for business logic encapsulation.

.. I've put some examples here
http://www.benorama.com/coldfusion/patterns/part3.htm

Benoit Hediard
www.benorama.com


-Message d'origine-
De : Raymond Camden [mailto:[EMAIL PROTECTED]]
Envoyé : dimanche 29 septembre 2002 21:06
À : CF-Talk
Objet : RE: So many problems with CFC scopes...



 For what reason? I've jumped in mid-thread here, but I'm
 really keen to get
 some good nitty-gritty low-down on the pros/cons/appropriate
 contexts for
 custom tags/UDFs/CFCs.

 I've had access to CF5 for a while, but most of my clients
 have been stuck
 on CF4.5 hosts, so I've not really got into the habit of
 UDFs. Now MX and
 CFCs are here, I feel I should dive into the whole lot
 knowing the practical
 differences and arguments for each method.

 You mentioned typing the extra reference for CFCs (i.e.
 myCFC.isEmail(...)
 as opposed to isEmail() for a UDF). Beyond that - which is
 obviously down to
 the kind of personal preference that's not worth debating -
 why would a CFC
 set of methods as opposed to a UDF library be not bad per
 se, just maybe
 not appropriate? What's the not appropriate bit, in
 performance/architecture terms, not personal
 preference/coding style terms?


Dave mentioned a collection of UDFs called Math that would serve as a
library. On a _completely_
personal level (ie, not performance, security, etc), I tend to think the
methods of a CFC should be
more tightly coupled - ie, have more of a reason then being together
than just being mathematical.

As a purely personal preference - that is why I wouldn't think it's
appropriate. Yes, I know it's a very
wishy-washy response - but as I said, it's a personal feeling. Also,
with CFCs being such a new beast,
what makes sense now and what makes sense 3 years from now will most
likely be somewhat different.

===
Raymond Camden, ColdFusion Jedi Master for Hire

Email: [EMAIL PROTECTED]
Yahoo IM : morpheus

My ally is the Force, and a powerful ally it is. - Yoda



__
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Gyrus]

Benoit, thanks for the summary of your rules-of-thumb for CF modularisation.
I'll check out your site later. For now, could you clear up some terminology
for this no-CS-background designer-turned-coder? ;-)

I can hazard good guesses, but what do you mean by view, controller and
model layers?

Also, I know the idea of business rules from relational DB design - am I
right in saying you're using business logic here in a similar sense, to
apply to the CF application? That is, it refers to procedures and functions
mostly specific to the current application?

If this is so, am I right in saying that, given your personal rules,
cflib.org for sharing UDFs is useful, but cfczone.org for sharing CFC's is
less useful? I know it's fine to use CFC's for generic functions and
cfczone.org will probably become as useful as cflib.org, I'm just trying to
gauge the meaning of your rules with this analogy. If you use CFCs for
business logic encapsulation, they may not be very portable - unless I'm
taking the term business logic in a too narrow sense.

- Gyrus


- [EMAIL PROTECTED]
work: http://www.tengai.co.uk
play: http://www.norlonto.net
- PGP key available



- Original Message -
From: Benoit Hediard [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, September 30, 2002 9:26 AM
Subject: UDF Vs CFC (was RE: So many problems with CFC scopes...)


 I agree with you Raymond.
 But it is true that is more personal preference/coding style terms than
 performance/architecture terms.

 This are my personal rules :
 CUSTOM TAGS (ColdFusion Taglibs)
 - custom tags encapsulates presentation logic they always output content
 (usually HTML),
 - custom tags usually do not call the model or controller layer,
 - custom tags are only used by the presentation layer (page or pagelet
 scripts).
  They are used for presentation logic encapsulation.

 USER DEFINED FUNCTIONS (UDF)
 - user defined functions encapsulate generic logic and rarely output
content
 (except for string formatting purposes),
 - user defined functions do not call the model or controller layer,
 - user defined functions are used in any layer (view, controller or
model).
  They are used generic logic/function encapsulation.

 COLDFUSION COMPONENTS (CFC)
 - components encapsulate business/data access application logic and never
 output content,
 - components are called by the view layer only to read data,
 - components are called by the controller layer to create/update/delete
 data.
  They are used for business logic encapsulation.

 .. I've put some examples here
 http://www.benorama.com/coldfusion/patterns/part3.htm

 Benoit Hediard
 www.benorama.com

__
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Benoit Hediard]

I can hazard good guesses, but what do you mean by view, controller and
 model layers?

Ooops... sorry.
It refers to the MVC pattern : Model View Controller.
- View : the presentation layer (there is usually a HTML-based view layer
generated by CFML pages),
- Controller : the application flow control, it receives request from the
View layer, executes application logic, calls the model layer and returns
the response to the View layer,
(in web app, it usually handles data posted by forms and then redirect to a
page)
- Model : the application business logic and data access layer (done with
CFCs in ColdfusionMX).

As for cfczone.org Vs udflib.org, it is true that they are going to overlapp
in some area.
All the 'udflib' functions might be encapsulated into CFCs and put on
'cfczone'...
And this is probably what is going to happen.

In our case, all our CFCs are linked to our application (and therefore to
our business logic) and could not be put or could not come from 'cfczone'.
All our UDFs are not linked to our application and are coming from 'udflib'.

But, in some cases CFCs might be more appropriate than UDF to encapsulate
generic logic : when you need to have an object-oriented logic.
Indeed, the advantage of CFCs over UDFs is their ability to have (or
simulate) an 'object-oriented/object-based' behaviour.
For example, CFC are great to be used as wrapper of existing java classes
(it keeps the object behaviour of the java class and hide its complexity).
With CFC, you can manipulate objects that are persistent during the
request :
- create an object,
- call object.method1(),
- call object.method2()...
The object keep his state/properties in between each calls.
With UDF, you can't really have this kind of approach.


So, for generic logic encapsulation, I would use :
- UDF / udflib.org for procedural logic (functions),
- CFC / cfczone.org for object-oriented logic.

But, again, this is in my opinion, so I prefer to stop here otherwise it is
going to be another never-ending thread... ;)
This is really a matter of personal preference/coding style.


Benoit Hediard
www.benorama.com

-Message d'origine-
De : Gyrus [mailto:[EMAIL PROTECTED]]
Envoyé : lundi 30 septembre 2002 14:03
À : CF-Talk
Objet : Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)


Benoit, thanks for the summary of your rules-of-thumb for CF modularisation.
I'll check out your site later. For now, could you clear up some terminology
for this no-CS-background designer-turned-coder? ;-)

I can hazard good guesses, but what do you mean by view, controller and
model layers?

Also, I know the idea of business rules from relational DB design - am I
right in saying you're using business logic here in a similar sense, to
apply to the CF application? That is, it refers to procedures and functions
mostly specific to the current application?

If this is so, am I right in saying that, given your personal rules,
cflib.org for sharing UDFs is useful, but cfczone.org for sharing CFC's is
less useful? I know it's fine to use CFC's for generic functions and
cfczone.org will probably become as useful as cflib.org, I'm just trying to
gauge the meaning of your rules with this analogy. If you use CFCs for
business logic encapsulation, they may not be very portable - unless I'm
taking the term business logic in a too narrow sense.

- Gyrus


- [EMAIL PROTECTED]
work: http://www.tengai.co.uk
play: http://www.norlonto.net
- PGP key available



- Original Message -
From: Benoit Hediard [EMAIL PROTECTED]
To: CF-Talk [EMAIL PROTECTED]
Sent: Monday, September 30, 2002 9:26 AM
Subject: UDF Vs CFC (was RE: So many problems with CFC scopes...)


 I agree with you Raymond.
 But it is true that is more personal preference/coding style terms than
 performance/architecture terms.

 This are my personal rules :
 CUSTOM TAGS (ColdFusion Taglibs)
 - custom tags encapsulates presentation logic they always output content
 (usually HTML),
 - custom tags usually do not call the model or controller layer,
 - custom tags are only used by the presentation layer (page or pagelet
 scripts).
  They are used for presentation logic encapsulation.

 USER DEFINED FUNCTIONS (UDF)
 - user defined functions encapsulate generic logic and rarely output
content
 (except for string formatting purposes),
 - user defined functions do not call the model or controller layer,
 - user defined functions are used in any layer (view, controller or
model).
  They are used generic logic/function encapsulation.

 COLDFUSION COMPONENTS (CFC)
 - components encapsulate business/data access application logic and never
 output content,
 - components are called by the view layer only to read data,
 - components are called by the controller layer to create/update/delete
 data.
  They are used for business logic encapsulation.

 .. I've put some examples here
 http://www.benorama.com/coldfusion/patterns/part3.htm

 Benoit Hediard

RE: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[S . Isaac Dealey]

 But, in some cases CFCs might be more appropriate than UDF to encapsulate
 generic logic : when you need to have an object-oriented logic.
 Indeed, the advantage of CFCs over UDFs is their ability to have (or
 simulate) an 'object-oriented/object-based' behaviour.
 For example, CFC are great to be used as wrapper of existing java
 classes
 (it keeps the object behaviour of the java class and hide its complexity).
 With CFC, you can manipulate objects that are persistent during the
 request :
 - create an object,
 - call object.method1(),
 - call object.method2()...
 The object keep his state/properties in between each calls.
 With UDF, you can't really have this kind of approach.

Actually you can if you structure the UDF's correctly, however, I would
expect CFC's in most cases to be a better solution... But as a for instance,
you could define a library of UDF's for an application which take in ID's
which the UDF's use to identify and manipulate objects which are persistent
in request or other scopes or which take in structures from those persistent
scopes. The syntax is different, but the end result is similar.

request.myobject.dump();

dump(request.myobject);

request.myobject.setShippingAddress(123 3rd St,Dallas,TX,55538);

setShippingAddress(reqeust.myobject,123 3rd St,Dallas,TX,55538);

Even before CF 5 and UDF's, some people managed to create object-oriented
features in ColdFusion using includes and cfmodules with things like
cfObjects and smartobjects and Tapestry was on its way there, though the
best of it didn't happen until CF5.

However, the syntax provided by CFC's or other object-oriented languages
does encourage thinking about the encapsulated functions or methods as a
part of the object, which is helpful, and I suspect they have other
advantages in addition.

 So, for generic logic encapsulation, I would use :
 - UDF / udflib.org for procedural logic (functions),
 - CFC / cfczone.org for object-oriented logic.

 But, again, this is in my opinion, so I prefer to stop here otherwise it
 is going to be another never-ending thread... ;)
 This is really a matter of personal preference/coding style.

Don't you mean www.cflib.org?


Question: (dunno if anyone has the answer to this) Do CFC's share methods in
memory, or does each new component created have its own instances of all the
functions defined in the cfc which take up their own space in memory? The
one way saves memory, the other way theoretically might allow you to modify
a method of one component on the fly without altering the definition of the
CFC.


S. Isaac Dealey
Certified Advanced ColdFusion 5 Developer

www.turnkey.to
954-776-0046
__
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Benoit Hediard]

 Don't you mean www.cflib.org?
Yes, sorry (why did i say www.udflib.org...? I don't know, at least it is
more clear for the explanation ;).

 Question: (dunno if anyone has the answer to this) Do CFC's share methods
in
 memory, or does each new component created have its own instances of all
the
 functions defined in the cfc which take up their own space in memory?

This is an excellent question.
I also wonder about this.

The thing I know is that once a CFC instance is loaded in a persistent scope
(session or application), if you modify the CFC definition, it is not taken
into account by the old CFC instance.
You have to reload a new instance to get the new definition.

Benoit Hediard

-Message d'origine-
De : S. Isaac Dealey [mailto:[EMAIL PROTECTED]]
Envoyé : lundi 30 septembre 2002 18:23
À : CF-Talk
Objet : RE: UDF Vs CFC (was RE: So many problems with CFC scopes...)


 But, in some cases CFCs might be more appropriate than UDF to encapsulate
 generic logic : when you need to have an object-oriented logic.
 Indeed, the advantage of CFCs over UDFs is their ability to have (or
 simulate) an 'object-oriented/object-based' behaviour.
 For example, CFC are great to be used as wrapper of existing java
 classes
 (it keeps the object behaviour of the java class and hide its complexity).
 With CFC, you can manipulate objects that are persistent during the
 request :
 - create an object,
 - call object.method1(),
 - call object.method2()...
 The object keep his state/properties in between each calls.
 With UDF, you can't really have this kind of approach.

Actually you can if you structure the UDF's correctly, however, I would
expect CFC's in most cases to be a better solution... But as a for instance,
you could define a library of UDF's for an application which take in ID's
which the UDF's use to identify and manipulate objects which are persistent
in request or other scopes or which take in structures from those persistent
scopes. The syntax is different, but the end result is similar.

request.myobject.dump();

dump(request.myobject);

request.myobject.setShippingAddress(123 3rd St,Dallas,TX,55538);

setShippingAddress(reqeust.myobject,123 3rd St,Dallas,TX,55538);

Even before CF 5 and UDF's, some people managed to create object-oriented
features in ColdFusion using includes and cfmodules with things like
cfObjects and smartobjects and Tapestry was on its way there, though the
best of it didn't happen until CF5.

However, the syntax provided by CFC's or other object-oriented languages
does encourage thinking about the encapsulated functions or methods as a
part of the object, which is helpful, and I suspect they have other
advantages in addition.

 So, for generic logic encapsulation, I would use :
 - UDF / udflib.org for procedural logic (functions),
 - CFC / cfczone.org for object-oriented logic.

 But, again, this is in my opinion, so I prefer to stop here otherwise it
 is going to be another never-ending thread... ;)
 This is really a matter of personal preference/coding style.

Don't you mean www.cflib.org?


Question: (dunno if anyone has the answer to this) Do CFC's share methods in
memory, or does each new component created have its own instances of all the
functions defined in the cfc which take up their own space in memory? The
one way saves memory, the other way theoretically might allow you to modify
a method of one component on the fly without altering the definition of the
CFC.


S. Isaac Dealey
Certified Advanced ColdFusion 5 Developer

www.turnkey.to
954-776-0046

__
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: So many problems with CFC scopes...

[Sean A Corfield]

On Sunday, Sep 29, 2002, at 12:06 US/Pacific, Raymond Camden wrote:
 You mentioned typing the extra reference for CFCs (i.e.
 myCFC.isEmail(...)
 as opposed to isEmail() for a UDF). Beyond that

There's also the code needed to create the 'myCFC' instance (setting 
myCFC = createObject(component,math) for example).

 Dave mentioned a collection of UDFs called Math that would serve as a
 library. On a _completely_
 personal level (ie, not performance, security, etc), I tend to think 
 the
 methods of a CFC should be
 more tightly coupled - ie, have more of a reason then being together
 than just being mathematical.

I agree although Java does a few things akin to this (which I don't 
like). Certainly in C++ this sort of aggregation was considered 
extremely poor style.

The main issue in my mind is that CF does not have static methods. You 
cannot call a method without creating an instance to call it against.

OTOH, a UDF library is purely static - there's no data instance 
required in order to call the functions. That's a big difference.

I have always wished that my computer would be as easy to use as my 
telephone.
  My wish has come true - I no longer know how to use my telephone.
-- Bjarne Stroustrup

__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Sean A Corfield]

On Monday, Sep 30, 2002, at 09:23 US/Pacific, S. Isaac Dealey wrote:
 Question: (dunno if anyone has the answer to this) Do CFC's share 
 methods in
 memory, or does each new component created have its own instances of 
 all the
 functions defined in the cfc which take up their own space in memory? 
 The
 one way saves memory, the other way theoretically might allow you to 
 modify
 a method of one component on the fly without altering the definition 
 of the
 CFC.

Each instance has a public data member which is the 'pointer' to the 
function but the actual function code is shared between all instances. 
What that means is if you have a CFC with 20 public methods, then each 
instance will contain 20 'pointers' to that code.

An Architect's View -- http://www.corfield.org/blog/

Macromedia DevCon 2002, October 27-30, Orlando, Florida
Architecting a New Internet Experience
Register today at http://www.macromedia.com/go/devcon2002

__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Rob Brooks-Bilson]

Sorry, jumping in late here...

I did some performance testing recently too see if it was faster to
CFINCLUDE a UDF library containing 50 UDFs, or instantiate a CFC with the
same 50 CFCs as methods.  The results were that the CFINCLUDE was
substantially faster on initial page load and all subsequent page loads.
As a side note, I tested CFML tag based UDFs vs. CFSCRIPT based UDFs too,
and the CFSCRIPT UDFs executed slightly faster than their tag based
cousins.

-Rob


Date: Mon, 30 Sep 2002 10:26:29 +0200
From: Benoit Hediard [EMAIL PROTECTED]
Subject: UDF Vs CFC (was RE: So many problems with CFC scopes...)
Message-ID: [EMAIL PROTECTED]

I agree with you Raymond.
But it is true that is more personal preference/coding style terms than
performance/architecture terms.

This are my personal rules :
CUSTOM TAGS (ColdFusion Taglibs)
- custom tags encapsulates presentation logic they always output content
(usually HTML),
- custom tags usually do not call the model or controller layer,
- custom tags are only used by the presentation layer (page or pagelet
scripts).
 They are used for presentation logic encapsulation.

USER DEFINED FUNCTIONS (UDF)
- user defined functions encapsulate generic logic and rarely output
content
(except for string formatting purposes),
- user defined functions do not call the model or controller layer,
- user defined functions are used in any layer (view, controller or model).
 They are used generic logic/function encapsulation.

COLDFUSION COMPONENTS (CFC)
- components encapsulate business/data access application logic and never
output content,
- components are called by the view layer only to read data,
- components are called by the controller layer to create/update/delete
data.
 They are used for business logic encapsulation.

.. I've put some examples here
http://www.benorama.com/coldfusion/patterns/part3.htm

Benoit Hediard
www.benorama.com


FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[Sean A Corfield]

On Monday, Sep 30, 2002, at 20:09 US/Pacific, Rob Brooks-Bilson wrote:
 I did some performance testing recently too see if it was faster to
 CFINCLUDE a UDF library containing 50 UDFs, or instantiate a CFC with 
 the
 same 50 CFCs as methods.  The results were that the CFINCLUDE was
 substantially faster on initial page load and all subsequent page 
 loads.

That's good to know - it fits in with my expectations and is exactly 
why, if you must do this kind of stuff, I would recommend creating just 
a single CFC instance and saving it in server scope (since a 'UDF 
library CFC' will have no state and probably shouldn't be generating 
any output!).

An Architect's View -- http://www.corfield.org/blog/

Macromedia DevCon 2002, October 27-30, Orlando, Florida
Architecting a New Internet Experience
Register today at http://www.macromedia.com/go/devcon2002

__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)

[S . Isaac Dealey]

 On Monday, Sep 30, 2002, at 09:23 US/Pacific, S. Isaac
 Dealey wrote:
 Question: (dunno if anyone has the answer to this) Do
 CFC's share
 methods in
 memory, or does each new component created have its own
 instances of
 all the
 functions defined in the cfc which take up their own
 space in memory?
 The
 one way saves memory, the other way theoretically might
 allow you to
 modify
 a method of one component on the fly without altering the
 definition
 of the
 CFC.

 Each instance has a public data member which is the
 'pointer' to the
 function but the actual function code is shared between
 all instances.
 What that means is if you have a CFC with 20 public
 methods, then each
 instance will contain 20 'pointers' to that code.

Awesome... Much more efficient this way. :) And the functionality which is
potentially lost is something that would see very little use anyhow -- ( and
I think liable to be problematic and cause confusion, so probably best
avoided anyway ) ... but I was curious about the way it was implemented.
This was what I suspected... my Tapestry cms currently works on a very
similar model in CF 5 using libraries of custom tags as the methods, and
structure elements as pointers where the key is the name of the method and
the value being a relative path to the custom tag, which allows the methods
to be inherited from parent classes. Good to know there's a parallel there,
even if it's not necessarily practical knowledge. :)

Isaac
Certified Advanced ColdFusion 5 Developer

www.turnkey.to
954-776-0046

__
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
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Raymond Camden]

   However, I would strongly argue that in CFMX you really 
   should no longer be using cfinclude'd UDF libraries. The 
   libraries should be converted to CFCs. If you're worried 
   about performance, don't be.  
  
  This is 100% wrong. At least in my opinion. UDFs are NOT the 
  same beast as CFCs, and there are cases when you should use 
  one or the other. 
 
 Really? I think this argument is pretty compelling. I see no 
 reason why you
 shouldn't use CFCs as static classes, or simply containers 
 for UDFs that
 are related in some way or another. Personally, I think the 
 idea of a static
 Math CFC is as useful as a CFINCLUDE that contains a bunch of math
 functions. In the worst case, it seems like six of one, a 
 half dozen of
 another. I'm curious about your reasoning on this.
 

I'm not saying you can't use a CFC as a UDF library, I'm saying that it
is wrong to say
UDFs are no longer necessary. Just like the introduction of UDFs did not
make custom tags
unnecessary, the same applies here. If you use a CFC as a UDF library,
your automatically
adding more typing to your code, which certainly isn't the end of the
world, but I'd rather

cfif isEmail(...)

than 

cfif myCFC.isEmail(...)

It's not just the typing per se, but the style as well, which as you say
may be 6of1. 

You also need to remember that a CFC != a UDF. I know you know that, and
most people, but
it may be easy for a developer to forget the architectural differences
between them. 

Again - my main comment is that it's wrong to say you should NOT uses
UDFs. I wouldn't use
a CFC as a UDF library, but I don't see it as bad per se, just maybe not
appropriate.

===
Raymond Camden, ColdFusion Jedi Master for Hire

Email: [EMAIL PROTECTED]
Yahoo IM : morpheus

My ally is the Force, and a powerful ally it is. - Yoda 


__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: So many problems with CFC scopes...

[Gyrus]

- Original Message -
From: Raymond Camden [EMAIL PROTECTED]
 Again - my main comment is that it's wrong to say you should NOT uses
 UDFs. I wouldn't use
 a CFC as a UDF library, but I don't see it as bad per se, just maybe not
 appropriate.


For what reason? I've jumped in mid-thread here, but I'm really keen to get
some good nitty-gritty low-down on the pros/cons/appropriate contexts for
custom tags/UDFs/CFCs.

I've had access to CF5 for a while, but most of my clients have been stuck
on CF4.5 hosts, so I've not really got into the habit of UDFs. Now MX and
CFCs are here, I feel I should dive into the whole lot knowing the practical
differences and arguments for each method.

You mentioned typing the extra reference for CFCs (i.e. myCFC.isEmail(...)
as opposed to isEmail() for a UDF). Beyond that - which is obviously down to
the kind of personal preference that's not worth debating - why would a CFC
set of methods as opposed to a UDF library be not bad per se, just maybe
not appropriate? What's the not appropriate bit, in
performance/architecture terms, not personal preference/coding style terms?

- Gyrus


- [EMAIL PROTECTED]
work: http://www.tengai.co.uk
play: http://www.norlonto.net
- PGP key available



__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Raymond Camden]

 
 For what reason? I've jumped in mid-thread here, but I'm 
 really keen to get
 some good nitty-gritty low-down on the pros/cons/appropriate 
 contexts for
 custom tags/UDFs/CFCs.
 
 I've had access to CF5 for a while, but most of my clients 
 have been stuck
 on CF4.5 hosts, so I've not really got into the habit of 
 UDFs. Now MX and
 CFCs are here, I feel I should dive into the whole lot 
 knowing the practical
 differences and arguments for each method.
 
 You mentioned typing the extra reference for CFCs (i.e. 
 myCFC.isEmail(...)
 as opposed to isEmail() for a UDF). Beyond that - which is 
 obviously down to
 the kind of personal preference that's not worth debating - 
 why would a CFC
 set of methods as opposed to a UDF library be not bad per 
 se, just maybe
 not appropriate? What's the not appropriate bit, in
 performance/architecture terms, not personal 
 preference/coding style terms?
 

Dave mentioned a collection of UDFs called Math that would serve as a
library. On a _completely_
personal level (ie, not performance, security, etc), I tend to think the
methods of a CFC should be
more tightly coupled - ie, have more of a reason then being together
than just being mathematical. 

As a purely personal preference - that is why I wouldn't think it's
appropriate. Yes, I know it's a very
wishy-washy response - but as I said, it's a personal feeling. Also,
with CFCs being such a new beast,
what makes sense now and what makes sense 3 years from now will most
likely be somewhat different.

===
Raymond Camden, ColdFusion Jedi Master for Hire

Email: [EMAIL PROTECTED]
Yahoo IM : morpheus

My ally is the Force, and a powerful ally it is. - Yoda 


__
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Benoit Hediard]

Unfortunately, to put the not IsDefined() right inside the UDF library
template doesn't work in CFMX either.
The test has to be done before the cfinclude of the UDF lib.
So there isnt't any nice workaround except to wrap each cfinclude of a UDF
lib around a not IsDefined().

As for the suggestion to convert all the UDF lib into CFC, I am not sure it
might be appropriate all the time.
The UDF lib allows you to add new CF language functions, so it is very good
for readibility.

For example, I personaly prefer to use

cfinclude template=StringLib.cfm
..
cfif isEmail(Email)
..

instead of

cfobject type=component name=StringLib
component=com.mycompany.lib.StringLib
..
cfif StringLib.isEmail(Email)
..

I agree that it could be done with CFC but I prefer to keep CFC to
encapsulate business logic linked to the application and use UDF to define
generic language functions (cross-applications).
That's just a matter of choice, but I may change my mind...


Benoit Hediard
www.benorama.com


-Message d'origine-
De : Samuel Neff [mailto:[EMAIL PROTECTED]]
Envoyé : samedi 28 septembre 2002 05:26
À : CF-Talk
Objet : RE: So many problems with CFC scopes...


Mark,

That actually won't work--at least it didn't in CF5, I haven't tested in
in CFMX.

The issue is that CF pre-processes the UDF declarations.  Putting a UDF
inside an if(){} statement won't prevent the UDF from being declared
twice and an error erupting.

You have to use a cfif testcfinclude udflib/cfif construct to
avoid the error.

However, I would strongly argue that in CFMX you really should no longer
be using cfinclude'd UDF libraries.  The libraries should be converted
to CFCs.  If you're worried about performance, don't be.  This should be
just as fast as using a CFINCLUDEd UDF lib--Ben Forta recently reported
at a CFUG that internal tests showed calls to a CFC to be faster than a
CFINCLUDE template--but even if using a CFC is slightly slower, the
benefits greatly outweigh the drawbacks (greater code
encapsulation/reuse/documentation vs. very slight loss in performance).

HTH,

Sam


Date: Fri, 27 Sep 2002 15:24:00 -0400
From: Gaulin, Mark [EMAIL PROTECTED]
Subject: RE: So many problems with CFC scopes...
Message-ID:
[EMAIL PROTECTED]

Why not put the not IsDefined() test right inside any udf library that
can
potentially be included more than one time?  (Just put the body of the
udf
inside the CFIF block.)

This is like the old #ifndef _MYFILE_H_, #define _MYFILE_H_ style
that
is used all the time in C and C++ programming.
Mark



__
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Raymond Camden]

 However, I would strongly argue that in CFMX you really 
 should no longer
 be using cfinclude'd UDF libraries.  The libraries should be converted
 to CFCs.  If you're worried about performance, don't be.  

This is 100% wrong. At least in my opinion. UDFs are NOT the same beast
as CFCs, and there are cases when you should use one or the other.


===
Raymond Camden, ColdFusion Jedi Master for Hire

Email: [EMAIL PROTECTED]
Yahoo IM : morpheus

My ally is the Force, and a powerful ally it is. - Yoda 


__
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Dave Watts]

  However, I would strongly argue that in CFMX you really 
  should no longer be using cfinclude'd UDF libraries. The 
  libraries should be converted to CFCs. If you're worried 
  about performance, don't be.  
 
 This is 100% wrong. At least in my opinion. UDFs are NOT the 
 same beast as CFCs, and there are cases when you should use 
 one or the other. 

Really? I think this argument is pretty compelling. I see no reason why you
shouldn't use CFCs as static classes, or simply containers for UDFs that
are related in some way or another. Personally, I think the idea of a static
Math CFC is as useful as a CFINCLUDE that contains a bunch of math
functions. In the worst case, it seems like six of one, a half dozen of
another. I'm curious about your reasoning on this.

Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
voice: (202) 797-5496
fax: (202) 797-5444

__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Benoit Hediard]

I think I forgot some other problems with CFCs linked to UDF lib functions.
It took me sometime to understand why I was not able to include UDF lib in
some cases.

- CFC methods defined in an included file cannot really include UDF lib.
Indeed, CF refuses to include twice the same UDF lib in one single script,
which could be the case with two CFC included methods definition that use
the same UDF lib.
WORKAROUND : include the UDF lib at the top of the CFC before the
CFFunction method tags (even if only few methods of the CFC use it). But I
don't know if this is very nice for the CFC, especially if the UDF lib is
based on cffunction tag which the same than the one used to define CFC
methods...

- UDF lib cannot be included in a CFC if the UDF lib is already included in
the script calling the CFC. This is a problem : if you want to use the CFC
in another script, you have to think to include the UDF lib before to invoke
the CFC...
WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
already be included.

All this is not very clean...
I wonder if it could be possible that CF accept to include several times the
same UDF lib : if it is the same file, it should not complain about it.
It would solve all those problems.

Any other CFC problems + workaround comes to your mind?


Benoit Hediard
http://www.benorama.com



-Message d'origine-
De : Benoit Hediard [mailto:[EMAIL PROTECTED]]
Envoyé : jeudi 26 septembre 2002 20:32
À : CF-Talk
Objet : So many problems with CFC scopes...


Hi,

I was wondering if anyone know when MM is going to fix all the issues
related to CFC scopes.
I was hoping for the CFMX updater, but it hasn't solve anything on those
issues.

It makes CFC development very weird, you need to use many workarounds,
especially when includes are used for methods definition.

Issues :
- CFCs used in persistent scope (session, application...) loose the page
context and cannot access other persistent scopes variables.
WORKAROUND :
http://webforums.macromedia.com/coldfusion/messageview.cfm?catid=8threadid=
386634

- The variable. scope is not private.
WORKAROUND : use the un-named scope
(http://cfguru.daemon.com.au/archives/67.html)

- methods defined in an included file loose the argument scope,
WORKAROUND : put the 'argument' scope in 'request' or 'this' scope to pass
it to the included method

- methods defined in an included file cannot call private or package
methods of the same CFC,
WORKAROUND : use only public or remote access security... :(

Any other problems related to CFC scopes to your mind or better workarounds?


Benoit Hediard
http://www.benorama.com


__
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
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Re: So many problems with CFC scopes...

[Sean A Corfield]

I'm going to look the other issues up in the bugbase in the next few 
days and see what's there but I'll address these issues here...

On Friday, Sep 27, 2002, at 02:36 US/Pacific, Benoit Hediard wrote:
 - CFC methods defined in an included file cannot really include UDF 
 lib.
 Indeed, CF refuses to include twice the same UDF lib in one single 
 script,
 which could be the case with two CFC included methods definition that 
 use
 the same UDF lib.

Because you cannot have more than one definition of a function - which 
is what happens when you include the UDF multiple times. You can't do 
this in most other languages (define the same function twice) so I 
don't know why you'd expect it to work in CF.

 - UDF lib cannot be included in a CFC if the UDF lib is already 
 included in
 the script calling the CFC.

This is essentially the same problem as above.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one 
function per include file...

 I wonder if it could be possible that CF accept to include several 
 times the
 same UDF lib : if it is the same file, it should not complain about it.

What if the file changes during the processing of the request?

I have always wished that my computer would be as easy to use as my 
telephone.
  My wish has come true - I no longer know how to use my telephone.
-- Bjarne Stroustrup

__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Benoit Hediard]

 I'm going to look the other issues up in the bugbase in the next few
 days and see what's there but I'll address these issues here...

Thanks Sean, you're the best.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one
function per include file...

If we have to implement manually cfif isDefined(function) each time we
want to include a UDF lib, I was wondering why this is not automatically
done by CF. If the function is already defined and the new definition is
identical to the first one, CF might ignore the second definition instead of
throwing an error.
It would save us a lot of work and possible errors (if someone forget the
cfif isDefined()).

I agree that CF should throw an error if the method definition is different
(defined in another template lib than the previous one), but not if the
method definition is identical (defined in the same template lib than the
previous one).
Is it impossible to implement?

With complex CFCs, I personally find that it is much cleaner and easier to
only define
the necessary UDF lib inside each included CFC method files
instead of
all the necessary UDF lib at the top of the CFC (especially if you use one
function per include file with cfif isDefined() around each).

 What if the file changes during the processing of the request?

Would it give problems?
If the template is changed during the processing of the request, the new
function definition would be ignored (defined in the same template than the
previous one), isn't it?


I agree that the cfif isDefined() is OK, but I am just curious to know
if the UDF lib include behaviour could be improved.


Benoit Hediard

-Message d'origine-
De : Sean A Corfield [mailto:[EMAIL PROTECTED]]
Envoyé : vendredi 27 septembre 2002 19:39
À : CF-Talk
Objet : Re: So many problems with CFC scopes...


I'm going to look the other issues up in the bugbase in the next few
days and see what's there but I'll address these issues here...

On Friday, Sep 27, 2002, at 02:36 US/Pacific, Benoit Hediard wrote:
 - CFC methods defined in an included file cannot really include UDF
 lib.
 Indeed, CF refuses to include twice the same UDF lib in one single
 script,
 which could be the case with two CFC included methods definition that
 use
 the same UDF lib.

Because you cannot have more than one definition of a function - which
is what happens when you include the UDF multiple times. You can't do
this in most other languages (define the same function twice) so I
don't know why you'd expect it to work in CF.

 - UDF lib cannot be included in a CFC if the UDF lib is already
 included in
 the script calling the CFC.

This is essentially the same problem as above.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one
function per include file...

 I wonder if it could be possible that CF accept to include several
 times the
 same UDF lib : if it is the same file, it should not complain about it.

What if the file changes during the processing of the request?

I have always wished that my computer would be as easy to use as my
telephone.
  My wish has come true - I no longer know how to use my telephone.
-- Bjarne Stroustrup


__
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Gaulin, Mark]

Why not put the not IsDefined() test right inside any udf library that can
potentially be included more than one time?  (Just put the body of the udf
inside the CFIF block.)

This is like the old #ifndef _MYFILE_H_, #define _MYFILE_H_ style that
is used all the time in C and C++ programming. 
Mark

-Original Message-
From: Benoit Hediard [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 27, 2002 2:43 PM
To: CF-Talk
Subject: RE: So many problems with CFC scopes...


 I'm going to look the other issues up in the bugbase in the next few
 days and see what's there but I'll address these issues here...

Thanks Sean, you're the best.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one
function per include file...

If we have to implement manually cfif isDefined(function) each time we
want to include a UDF lib, I was wondering why this is not automatically
done by CF. If the function is already defined and the new definition is
identical to the first one, CF might ignore the second definition instead of
throwing an error.
It would save us a lot of work and possible errors (if someone forget the
cfif isDefined()).

I agree that CF should throw an error if the method definition is different
(defined in another template lib than the previous one), but not if the
method definition is identical (defined in the same template lib than the
previous one).
Is it impossible to implement?

With complex CFCs, I personally find that it is much cleaner and easier to
only define
the necessary UDF lib inside each included CFC method files
instead of
all the necessary UDF lib at the top of the CFC (especially if you use one
function per include file with cfif isDefined() around each).

 What if the file changes during the processing of the request?

Would it give problems?
If the template is changed during the processing of the request, the new
function definition would be ignored (defined in the same template than the
previous one), isn't it?


I agree that the cfif isDefined() is OK, but I am just curious to know
if the UDF lib include behaviour could be improved.


Benoit Hediard

-Message d'origine-
De : Sean A Corfield [mailto:[EMAIL PROTECTED]]
Envoyé : vendredi 27 septembre 2002 19:39
À : CF-Talk
Objet : Re: So many problems with CFC scopes...


I'm going to look the other issues up in the bugbase in the next few
days and see what's there but I'll address these issues here...

On Friday, Sep 27, 2002, at 02:36 US/Pacific, Benoit Hediard wrote:
 - CFC methods defined in an included file cannot really include UDF
 lib.
 Indeed, CF refuses to include twice the same UDF lib in one single
 script,
 which could be the case with two CFC included methods definition that
 use
 the same UDF lib.

Because you cannot have more than one definition of a function - which
is what happens when you include the UDF multiple times. You can't do
this in most other languages (define the same function twice) so I
don't know why you'd expect it to work in CF.

 - UDF lib cannot be included in a CFC if the UDF lib is already
 included in
 the script calling the CFC.

This is essentially the same problem as above.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one
function per include file...

 I wonder if it could be possible that CF accept to include several
 times the
 same UDF lib : if it is the same file, it should not complain about it.

What if the file changes during the processing of the request?

I have always wished that my computer would be as easy to use as my
telephone.
  My wish has come true - I no longer know how to use my telephone.
-- Bjarne Stroustrup



__
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
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Benoit Hediard]

Indeed, this is also another solution, probably the best one right now!

Benoit Hediard

-Message d'origine-
De : Gaulin, Mark [mailto:[EMAIL PROTECTED]]
Envoyé : vendredi 27 septembre 2002 21:24
À : CF-Talk
Objet : RE: So many problems with CFC scopes...


Why not put the not IsDefined() test right inside any udf library that can
potentially be included more than one time?  (Just put the body of the udf
inside the CFIF block.)

This is like the old #ifndef _MYFILE_H_, #define _MYFILE_H_ style that
is used all the time in C and C++ programming.
Mark

-Original Message-
From: Benoit Hediard [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 27, 2002 2:43 PM
To: CF-Talk
Subject: RE: So many problems with CFC scopes...


 I'm going to look the other issues up in the bugbase in the next few
 days and see what's there but I'll address these issues here...

Thanks Sean, you're the best.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one
function per include file...

If we have to implement manually cfif isDefined(function) each time we
want to include a UDF lib, I was wondering why this is not automatically
done by CF. If the function is already defined and the new definition is
identical to the first one, CF might ignore the second definition instead of
throwing an error.
It would save us a lot of work and possible errors (if someone forget the
cfif isDefined()).

I agree that CF should throw an error if the method definition is different
(defined in another template lib than the previous one), but not if the
method definition is identical (defined in the same template lib than the
previous one).
Is it impossible to implement?

With complex CFCs, I personally find that it is much cleaner and easier to
only define
the necessary UDF lib inside each included CFC method files
instead of
all the necessary UDF lib at the top of the CFC (especially if you use one
function per include file with cfif isDefined() around each).

 What if the file changes during the processing of the request?

Would it give problems?
If the template is changed during the processing of the request, the new
function definition would be ignored (defined in the same template than the
previous one), isn't it?


I agree that the cfif isDefined() is OK, but I am just curious to know
if the UDF lib include behaviour could be improved.


Benoit Hediard

-Message d'origine-
De : Sean A Corfield [mailto:[EMAIL PROTECTED]]
Envoyé : vendredi 27 septembre 2002 19:39
À : CF-Talk
Objet : Re: So many problems with CFC scopes...


I'm going to look the other issues up in the bugbase in the next few
days and see what's there but I'll address these issues here...

On Friday, Sep 27, 2002, at 02:36 US/Pacific, Benoit Hediard wrote:
 - CFC methods defined in an included file cannot really include UDF
 lib.
 Indeed, CF refuses to include twice the same UDF lib in one single
 script,
 which could be the case with two CFC included methods definition that
 use
 the same UDF lib.

Because you cannot have more than one definition of a function - which
is what happens when you include the UDF multiple times. You can't do
this in most other languages (define the same function twice) so I
don't know why you'd expect it to work in CF.

 - UDF lib cannot be included in a CFC if the UDF lib is already
 included in
 the script calling the CFC.

This is essentially the same problem as above.

 WORKAROUND : use the cfif isDefined(oneOfTheFunctionName)cfinclude
 template=myUDFlib.cfm/cfif in the CFC to test if the UDF lib has
 already be included.

Yes, that is what we do here. It also encourages you to have one
function per include file...

 I wonder if it could be possible that CF accept to include several
 times the
 same UDF lib : if it is the same file, it should not complain about it.

What if the file changes during the processing of the request?

I have always wished that my computer would be as easy to use as my
telephone.
  My wish has come true - I no longer know how to use my telephone.
-- Bjarne Stroustrup




__
This list and all House of Fusion resources hosted by CFHosting.com. The place for 
dependable ColdFusion Hosting.
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

RE: So many problems with CFC scopes...

[Samuel Neff]

Mark,

That actually won't work--at least it didn't in CF5, I haven't tested in
in CFMX.

The issue is that CF pre-processes the UDF declarations.  Putting a UDF
inside an if(){} statement won't prevent the UDF from being declared
twice and an error erupting.

You have to use a cfif testcfinclude udflib/cfif construct to
avoid the error.

However, I would strongly argue that in CFMX you really should no longer
be using cfinclude'd UDF libraries.  The libraries should be converted
to CFCs.  If you're worried about performance, don't be.  This should be
just as fast as using a CFINCLUDEd UDF lib--Ben Forta recently reported
at a CFUG that internal tests showed calls to a CFC to be faster than a
CFINCLUDE template--but even if using a CFC is slightly slower, the
benefits greatly outweigh the drawbacks (greater code
encapsulation/reuse/documentation vs. very slight loss in performance).

HTH,

Sam


Date: Fri, 27 Sep 2002 15:24:00 -0400
From: Gaulin, Mark [EMAIL PROTECTED]
Subject: RE: So many problems with CFC scopes...
Message-ID:
[EMAIL PROTECTED]

Why not put the not IsDefined() test right inside any udf library that
can
potentially be included more than one time?  (Just put the body of the
udf
inside the CFIF block.)

This is like the old #ifndef _MYFILE_H_, #define _MYFILE_H_ style
that
is used all the time in C and C++ programming. 
Mark


__
Your ad could be here. Monies from ads go to support these lists and provide more 
resources for the community. http://www.fusionauthority.com/ads.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists