Check out BlueDragon as it allows for true code compilation and many features rumoured to make it into CF 7 (aka Blackstone).
Peter Tilbrook Manager, ACT and Region ColdFusion Users Group - http://www.actcfug.com 4/73 Tharwa Road Queanbeyan, NSW, 2620 AUSTRALIA Telephone: +61-2-6284-2727 Mobile: +61-0439-401-823 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Barnes Sent: Wednesday, 7 July 2004 5:39 PM To: CFAussie Mailing List Subject: [cfaussie] Re: Packages dir in the webroot? Robin Hilliard wrote: > > Scott Barnes wrote: > >> >> Q. What are the bads for having your CFC's exposed to the web? ie: >> >> www.spidaweb.com/myApp/ >> www.spidaweb.com/myApp/packages/ >> www.spidaweb.com/myApp/packages/module/blah.cfc >> >> www.spidaweb.com/myApp/views/ >> www.spidaweb.com/myApp/views/index.cfm > > > There are plenty of reasons not to expose more than necessary under > the webroot - in some cases Application.cfm is no defence, I've seen > sourcecode downloaded sometimes when the JRun server isn't running. I Very good point, thats the reason i guess i was primarily after. Having said that if JRUN isn't running we are basically [EMAIL PROTECTED] as they then could actually download all the .cfm files? which would be bad in many cases.. We don't keep DSN U&P in our cfm code / configuration files as to me i'd rather let CFAdministrator handle that (well i've been taught its just as good and more secure - provided your not on a shared hosting environment). Loosing the JRUN in an equation has some scarey consequences and i think that alone would be the kiss of death for an app (even though we use the stock standard encryption for the avg hack script kiddy to be dazzled with). > suppose the reasons you would want to do this are to either: > > a) Expose components with remote methods, or These are public methods but the remote side of things is a possibility, but i'd be inclined to setup an overall WSDL wrapper cfc for this anyway. > b) Make deployment easier with everything under a single directory tree. heh hit the nail on the head. Our biggest support issue to date is not the code in many ways its more the deployment, and for now i'd rather wrap it all in a nice bundle and go "f#*kyou very much, and here you go"... i say that as a joke ;) - i'm in a sarcastic mood so please don't be offended with my bleeped swearing. > For (a) the number of classes exposed should be very limited - you may > want to arrange these in a package directory structure but the bulk of > your classes, tags and includes would still be outside the webroot. Read above. > For (b) if you're using the JRun version of CF you have a very handy > WEB-INF directory that cannot be browsed. You can put your packages > in here safely and deploy them in one lump with your webroot stuff > (and in fact your entire CF/Flex whatever installation). Sadly IIS is our monkey on the spot (ie supported web server, lots of valid reasons but more to do with clients not being apache experts or vice versa). I'd eventually like to lock our product if need be into its own standalone webserver with port number (ie cfserver as is). > What do I do (not claiming best-practise) is keep all my cfcs, > includes and custom tags in a package tree outside the web root. If I > have full control of the server I set the "/" mapping to the root of > my package tree, then I can refer to all the packages I use without > creating a cast of thousands on the mapping page: > com.rocketboots.VCard, org.camden.blog.Blog. If it's a J2EE install > sometimes I put the package tree in WEB-INF/classes. If I'm on a > shared server I ask for the /com, /org etc mappings instead of the / > mapping on the directories immediately below the top of the tree - if > you're the first to ask you can get them (and if you're on AusTiger's > mighty shared server, don't bother, I've got them already :-). > > BTW, I keep my includes and custom tags in the package hierachy > alongside my cfcs - often in an includes/ or tags/ directory - you can > sort of think of them as static methods of an includes or tags class > that way. Yeah another valid support point of soreness here is mappings....ouchy. I'd rather wrap it into a bundle and give it a rootbranch mapping and go from there for now. I'm hoping Blackstones deployment features may open up some interesting possibilities, but for now it'll be a "please don't loose the jrun service.." - mind you our products IP isn't in the CF its actually the database, how its interfaced isn't a sore point. But thankyou Robin for some good responses, I'll take them onboard and hand you a cheque when i'm rich and RocketBoots gets upgraded to RocketPants ;) Go the Maroons btw, Scott > > > ------------------------------------------------- > Robin Hilliard > Partner > RocketBoots Pty Ltd > Professional Services for Macromedia Technologies m +61 418 414 341 f > +61 2 9798 0070 e [EMAIL PROTECTED] w > http://www.rocketboots.com.au > ------------------------------------------------- > > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
