I see your point. To get around the issue, we're architecting our process where a custom tag that's selected for a page can reside in 1 of 2 possible locations: custom tag folder specific to the site the page is registered for, or a global custom tag folder where the custom tags are available for all sites. When I select a module (aka custom tag) for the page I'm editing, I know where the module is stored, so I create the appropriate <cfimport> tag when I programmatically create the CFM page.
Tom -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Churvis Sent: Monday, August 09, 2004 10:03 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] cfimport vs cfmodule Thomas, You'll still have the problems I mentioned moving from one environment to another, where the mapping you want to use may not be available on the destination machine. More often than not this won't bite you, but when it does you have a nice search-and-replace plus a complete regression test in front of you. Respectfully, Adam Phillip Churvis Member of Team Macromedia Advanced Intensive ColdFusion MX Training: * ColdFusion MX Master Class * Advanced Development with CFMX and SQL Server 2000 http://www.ColdFusionTraining.com Download CommerceBlocks V2.1 and LoRCAT from http://www.ProductivityEnhancement.com The ColdFusion MX Bible is in bookstores now! ----- Original Message ----- From: "Schreck, Thomas (PPC)" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 09, 2004 9:13 AM Subject: RE: [CFCDev] cfimport vs cfmodule Our problem is solved by using <cfimport> directly on the page where the custom tags are to be consumed. We are programmatically creating CFM pages based upon a wizard I've been developing for defining a page and its sections. Basically, each page is an object and each page is divided into sections. I have a web based table builder that defines the layout of the page. Next, I drag and drop custom tags onto the sections defined in the page layout. Finally, I generate the CFM file based upon the layout and selected custom tags. As I generate the CFM page, I write the appropriate <cfimport> tag where the selected custom tags reside. Bottom line is I can create any layout for a page and programmatically generate the page for my sites. I appreciate the feedback on <cfimport>. Thanks - Tom Schreck 817-252-4900 [EMAIL PROTECTED] I have not failed. I've found 10,000 ways that won't work. - Thomas Edison -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Churvis Sent: Sunday, August 08, 2004 10:30 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] cfimport vs cfmodule Our problem with using CFIMPORT is that you can't use a variable in the taglib attribute, which means you can't use a config file to define the location of the custom tags for a specific application. So you're in a jam if you're building a framework that might be used in multiple places on a shared host. This is because CFIMPORT is a compile-time directive, which also means you can't place it in your Application.cfm; instead, you have to place CFIMPORT directly on each page that calls one of the custom tags in your library. CFMODULE is great for solving this problem, but then you can't build custom tag editors for your custom tags because the tag actually being edited is CFMODULE, not your custom tag. We use the cf_ syntax so that we can use mappings, define the custom tag path in ColdFusion Administrator, and also build custom tag editors for our custom tags. The code produced using cf_ syntax is also much more compact and easier to read. Which brings us back to the whole shared hosting thing, because you can't bind a specific custom tag path defined in ColdFusion Administrator with a specific application, because ColdFusion doesn't have a true concept of an "application" like other platforms do. So now we're back to versioning problems when you have two custom tags with the same name anywhere on the same shared host box: which version does it call? The first one accessed since the last reboot, most likely, since ColdFusion caches the path to the custom tag once it finds it the first time. To solve this problem, we've created a little drag-and-drop utility for the ColdFusion community that enables you to drag your finalized code in your application root over the utility icon, and it creates a safe copy of your codebase with all cf_ syntax converted to CFMODULE syntax using Template="#Application.customtags#" to define the path. You simply define Application.customtags in your application's configuration file, and bada-bing!, no more shared hosting issues. We haven't posted this utility yet, so if anyone needs a copy just contact me offlist. Respectfully, Adam Phillip Churvis Member of Team Macromedia Advanced Intensive ColdFusion MX Training: * ColdFusion MX Master Class * Advanced Development with CFMX and SQL Server 2000 http://www.ColdFusionTraining.com Download CommerceBlocks V2.1 and LoRCAT from http://www.ProductivityEnhancement.com The ColdFusion MX Bible is in bookstores now! ----- Original Message ----- From: "Barney Boisvert" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, August 06, 2004 12:58 PM Subject: Re: [CFCDev] cfimport vs cfmodule > You're right, when you use TEMPLATE syntax you can use mappings, > exactly like CFINCLUDE. Apologies for the oversight, been so long > since I've used CFMODULE at all. la la la, I love Fridays, la la la. > > cheers, > barneyb > > On Fri, 06 Aug 2004 12:55:15 -0500, Raymond Camden <[EMAIL PROTECTED]> wrote: > > cfmodule also allows you to use to multiple versions of a tag - just use > > it with mappings. cf_foo however doesn't. > > > > Barney Boisvert wrote: > > > > > To build on what Ray said... > > > > > > Assuming a file named myTag.cfm in the same directory, all four of > > > these are identical in functionality; they differ only in syntax: > > > > > > <cfimport prefix="t" taglib="." /> > > > <t:myTag ... /> > > > > > > <cfmodule template="myTag.cfm" ... /> > > > > > > <cfmodule name="myTag" ... /> > > > > > > <cf_myTag ... /> > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
