Re: UDF Vs CFC (was RE: So many problems with CFC scopes...)
> 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: UDF Vs CFC (was RE: So many problems with CFC scopes...)
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...)
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...)
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...)
> 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: 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: UDF Vs CFC (was RE: So many problems with CFC scopes...)
>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) > - componen
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 > 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
