OK... granted. Custom tags on shared servers do expose themselves to other users (apps) and can sometimes even make the other persons custom tag show itself rather than the current users custom tags. (I had this happen to me... so this is validated.)
Mappings are a good solution when they are added to the application configuration of Application.cfc and if that takes priority. Until then the concept of mapping off "/" seems to be a good one in theory. Yet there is another issue you may not have crossed. On shared hosting servers they often offer "FREE SSL" so the url is not "https://www.mydomain.com/index.cfm"; instead it works something like this "https://secure2.myhostsecuredomain.com/mydomain/index.cfm"; and it doesn't work quite the same. (And here you thought life was getting simpler!) I see all the advantages you speak of... when the hosting environment provides for them. Yet, when it doesn't then the applications do not run. When the apps don't run people blame CF rather than the code written in CF. I therefore vote for the universal solution. (Not that anyone is voting that is.) If you use <cfimport> and create a tag package. I use something similar with my methodology to do class paths for my methodology. It works great and when I move apps from Build to Test and Test to Live they don't break. Graphics don't break links, page links don't break, CFCs are found, custom Tags are found... and I can still update everything from central locations. Mapping would be ideal if you could set a priority map in Application.cfc or CFApplication... but for now that isn't there for me. John Farrar -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert Sent: Sunday, November 06, 2005 12:44 AM To: [email protected] Subject: Re: [CFCDev] Factory Pattern If you drop your packages in the web root, you can reference them without mappings. To put it another way the web root is implictly mapped to "/". I can't think of a framework that forces you to use mappings, though there are advantages to doing it that way. For example, you can avoid duplicating framework code for each utilizing application, which makes bug fixes in the framework enormously easier to apply. It also ensures that you're never running mixed versions (because there's only one copy). There are other reasons as well. It's your call as to which is more appropriate. cheers, barneyb ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
