On Friday, Sep 19, 2003, at 23:09 US/Pacific, Adam Churvis wrote: > the two main things that got me about CFIMPORT was that > you couldn�t use a variable to target the custom tag library location > since > it�s a compile-time directive
Correct. You can use a mapping however and that can be controlled from the CF Admin - that's as 'dynamic' as it gets. > secondly "importing" the entire library > of custom tags at that location, which sounded like a lot of > unnecessary > overhead on each page request. Which you now know is not true! :) > Without that, our software wouldn�t be easy to deploy in a shared > environment where the mapping name you hard-coded into all those > CFIMPORT > calls during development wasn�t available when it came time to deploy > on a > box that had a hundred other sites on it-- and one of them got your > mapping > name first. Choose a mapping that uniquely identifies your software. If the software's that big and important, I doubt you'd want to deploy it on a box shared with "a hundred other sites", surely? > All this being said, would you seriously consider amending your > ColdFusion > MX Coding Guidelines regarding the use of CFMODULE? <cfmodule> is banned in our environment. I have, however, adjusted the wording to read: "Don't use cfmodule It's slower than a CFC method invocation, it's slower and uglier than using a custom tag with a prefix, it's even slightly slower than a regular custom tag invocation. Better options exist: use a CFC (preferred), use cfimport and invoke a custom tag (always preferable to invoking a custom tag via cfmodule) or even simply including a file." This will be in the 3.0.1 version that I'll put out shortly (allowing for more public input). > Just from this > discussion today, I don�t think the claim of "slow" really holds up > anymore, I disagree. In terms of straight line speed it is clearer slower than the cfimport/prefix invocation. > nor does the claim that it "encourages some very unstructured usage." Even tho' I've dropped that comment from the coding guidelines, I stand by it. <cfmodule> was introduced into the language to provide a workaround for the name clashes caused by the search order for custom tags. It was a patch, nothing more, because custom tags themselves are not a very structured way to program (but, back in the day, there was nothing better). CFCs provide much more structure so, except in places where a custom tag is more idiomatic - which the coding guidelines do allow for - custom tags in general are frowned upon here (by my team). > in light of what I�ve mentioned about maintainability (especially in > shared > hosting environments), CFIMPORT isn�t "always preferable" to CFMODULE. As I said, these coding guidelines are written from the perspective of the team that built macromedia.com and, for us, <cfimport> *is* always preferable to <cfmodule>. > I really want to clear up these rumors, and your > very influential guidelines document would be a great place to set the > record straight. Well, that document will continue to say "Don't use cfmodule" because I believe it is far from best practice with CFMX 6.1. Best practice changes over time. <cfmodule> might have been best practice in earlier versions of CF but now they are better ways to handle complex libraries of code. Sean A Corfield -- http://www.corfield.org/blog/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Message: http://www.houseoffusion.com/lists.cfm?link=i:4:137936 Archives: http://www.houseoffusion.com/lists.cfm?link=t:4 Subscription: http://www.houseoffusion.com/lists.cfm?link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. http://www.cfhosting.com
