RE: [CFCDev] component extends object with relative path

[Jim Davis]

It’s not that the code to make the DSNs is “official” – it’s just the process for doing so has been sorted out and settled on.  That hasn’t happened yet for CFCs.  Allaire/Macromedia also had white papers and best practices information for hosting providers – they don’t seem to do that anymore.   Simple apps can definitely work (although you must meet some pretty severe, I think, limitations) – it’s when you’re considering larger apps for sale that things definitely get murkier.   A simple example: I’ve create (as I think many people have) a “root” component – a component that is extended by all other components in my systems.  I want to package each system separately but still have access to that root component.  I also have several utility components that I want to use across systems.  There are also database-specific DAO components to find.  My directory might look like this (plus sign indicate directory names):   +CFCs             Rootcomponent.cfc             +Utilities                         Collection.cfc                         OrderCollection.cfc             +Framework                         Session.cfc                         Application.cfc                         +DAOSQLServer                                     SessionBroker.cfc                         +DAOAccess                                     SessionBroker.cfc                         +Blog                         Blog.cfc   And so forth – no problem if you can make a mapping to the CFCs folder, but impossible if you can’t.  There might be several dozen, if not several hundred CFCs across this structure.  You can “solve” the problem by placing everything in the same package but that’s not a solution in my mind.   Again – I’m not arguing in ANY WAY that CFCs, themselves, are useless or broken – I love ‘em.  I’m arguing that the discovery process for them is broken.  At the very least it’s heavily slanted to full admin access.  If you don’t have admin access there are definitely work arounds – but all have pretty severe drawbacks in my book.   I stand by my statement that to fully see the promise of CFCs you need admin access (as it stands).  More and more hosts are giving people that, but even then we’re still left with issue surrounding name conflicts and name caching (it’s pretty much impossible to use multiple versions of an advanced CFC application on a single host – but that’s a problem shared with Java).   My wishlist includes the ability to set CFC mappings at the APPLICATION level in addition to the server level.  Something like this would solve all of my problems:   <cfapplication name=”DepressedPress” …>             <cfapplicationparam type=”Mapping” path=”d:/roots/Depressedpress/CFCs” name=”CFCs”> </cfapplication>   It would be great to extend that idea to DSNs and such as well – but not nearly as necessary.  Such mapping would only be effective within that application – meaning that as long as you can come up with a unique application name you’ve no chance for conflicts with peers on the same server.   I know that we’re going to get some official programmatic access to the admin functions with the next release, but as far as I know that’s still server-wide settings (which means that most hosts will probably restrict them).  Allowing for application-level, programmer controlled, granularity would make hosting CF applications insanely easier.   Jim Davis