I think that problem of not necessarily understanding the pros and cons and
how to appropriately apply a given tool isn't just a CFC thing (because it's
new presumably). I think a lot of people still seem to be having trouble
figuring out the pros and cons and how to get the most out of xml, cflock,
custom tags, UDF's and even to some extent cfinclude.
The more subtle the idea or variation, the harder it is for people to grasp,
like the difference between custom tags and functions. I think a lot of
people are aware that functions tend to be faster than tags, but that
doesn't make functions inherently superior to tags. In some cases you would
need or even just want to use the slower custom tag because the UDF
equivalent would require some "ugly" code as a result of the functional
differences caused by the syntax.
(Pardon me while I speak in tongues ... blurt blisch egersch) ...
For example: sometimes you really want an end tag because you want to be
able to write out content in the middle, and although you can use
<cfsavecontent> or you can build all the content prior to a function call,
often it's just extra work and more "ugly" code to do so, i.e.:
<cf_myendedtag>
<html stuff="here">blah blah</html>
</cf_myendedtag>
Versus
<cfsavecontent variable="temp">
<html stuff="here">blah blah</html>
</cfsavecontent>
<cfoutput>#myfunction(temp)#</cfoutput>
Or:
<cfset myhtml = "<html stuff=""here"">blah blah</html>">
<cfoutput>#myfunction(temp)#</cfoutput>
These are short examples but it ought to show how as the code becomes larger
and more complex, the end-tag solution should remain cleaner and easier to
read than the alternatives.
Or on another note, because a function requires a rather specific set of
arguments to be passed in a specific order, there's no really graceful UDF
equivalent (that I'm aware of) to <cfmodule template="blah.cfm"
attributecollection="#mystructure#"> . This is not to say you can't do it.
You write a wrapper function that takes a structure and calls the original
function, but that requires writing the wapper function obviously and then
is possibly more processing time on the server which sort of defeats the
purpose of the UDF being faster (if that was your intention).
I'm not a big fan of using XML to store application setting either. Imho
they're better stored in CF and it's even possible to generate the CF
templates that generate your application settings from another CF app (an
installer). If you do store application settings in xml they really should
be stored in a .cfm template so that the CF Server will protect the data
from someone attempting to get at it from typing a URL into their browser,
especially if it's for a product that you intend to sell. Moreover, just
having a <cfinclude> template that gets drawn in to the top of the
application.cfm is less overhead for the application than deserializing an
xml packet -- and yes, you can write code to check for the existance of
application scope variables and only deserialize the packet when it's
needed, but then you're just doing a lot of extra work for the sake of using
xml rather than using xml for the purpose of solving a problem.
Then of course, there's cfinclude... ASP has no means of dynamically
including content, which is a big advantage in cf, but in most cases I don't
see cfincludes taking advantage of the fact that the template attribute is
dynamic. I see a lot of the FuseBox <cfswitch> method...
<cfswitch expression="#fusebox.fuseaction#">
<cfcase value="blah">
<cfinclude template="blah.cfm">
</cfcase>
<cfcase value="foo">
<cfinclude template="foo.cfm">
</cfcase>
<cfcase value="bar">
<cfinclude template="bar.cfm">
</cfcase>
</cfswitch>
Which is certainly a lot better than ASP ( since in ASP this code would
include and parse all three templates regardless of the value of the
variable), however, with a very little massaging of the variable in question
(to ensure it can't be used to hack the application) this code could be
reduced to something like:
<cfset fuseaction = rereplacenocase(fuseaction,"[^[:alnum:]]","","ALL")>
<cfinclude template="#fuseaction#.cfm">
Which is both less code and faster -- the only disadvantage is that you can
no longer perform a multi-file search through your application for "foo.cfm"
and produce this page, you would have to search for "foo". Imho it's a small
price to pay for a 10 line template vs. for instance a 500 line template
that runs the risk of breaching the Java 64k limit on MX.
Anyway ... I should get back to my work. ;P
s. isaac dealey 954-776-0046
new epoch http://www.turnkey.to
lead architect, tapestry cms http://products.turnkey.to
tapestry api is opensource http://www.turnkey.to/tapi
certified advanced coldfusion 5 developer
http://www.macromedia.com/v1/handlers/index.cfm?ID=21816
> Thanks Sean. You know the biggest problem I and perhaps
> others have with
> CFCs is not so much writing code that uses them, but
> writing code that uses
> them appropriately, i.e. in ways that don't dilute their
> value while still
> providing efficient code. So it's interesting to see
> recommendations like
> this.
> ----- Original Message -----
> From: "Sean A Corfield" <[EMAIL PROTECTED]>
> To: "CF-Talk" <[EMAIL PROTECTED]>
> Sent: Monday, March 31, 2003 5:42 AM
> Subject: Re: CFCs - get'ers Vs. return object
>> On Saturday, Mar 29, 2003, at 16:13 US/Pacific, Matthew
>> Walker wrote:
>> > I am only dabbling in CFCs but it seems sensible to me
>> > to retrieve a
>> > structure of related information using one getter, then
>> > just accessing
>> > that.
>> > But maybe I just don't "get" CFCs. Perhaps it's up to
>> > the CFC to cache
>> > that
>> > info so that endless database requests aren't required.
>> > For example,
>> > the
>> > first getSomething() could query the database for more
>> > than just the
>> > one
>> > requested field, and store the whole lot in a cache.
>> > Any following
>> > getSomethingElse() could grab the data from that cache.
>>
>> Yes, that's a pretty good way to implement it (so I'd say
>> that you do,
>> indeed, "get" CFCs). In fact, you could have a method
>> that gets all the
>> data, declared access="private", and then in each of your
>> 'getSomething()' methods, you test whether the data is
>> already in cache
>> and, if not, call the private 'getAllData()' method to
>> load it:
>>
>> <cfcomponent>
>> <cfset isCached = false>
>> <cffunction name="getAllData" access="private">
>> ... load all the data into some instance variable ...
>> <cfset isCached = true>
>> </cffunction>
>> <cffunction name="getSomething">
>> <cfif not isCached>
>> <cfset getAllData(...)>
>> </cfif>
>> <cfreturn myCache.something>
>> </cffunction>
>> </cfcomponent>
>>
>> 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/uns
> ubscribe.cfm?user=633.558.4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
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.
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
