RE: [CFCDev] Basic component inheritance path question

[Roland Collins]

No offense taken J   With the exception of a _single_ entry in the CF mappings table, I can currently deploy my application with little more than an xcopy.  There’s no reason it needs to be more complex than that, and no reason it should.  I don’t want to have to run an installer every time I install an instance of my app, nor do I want to have to run an uninstaller to clean it up afterwards.  If you’re deploying any more than a few instances of an app, installers get extremely tedious.  In fact, in a highly-secured environment, you frequently can’t even obtain the execute permissions to run an installer!  And let’s not forget our brethren who use shared hosting – there’s no _chance_ they’re going to be able to log into a server and run a setup routine.   Besides, why would you want to have to modify source code in order to get the application to run for every deployment?  Personally, I want all of my deployed code to be _exactly_ the same.  I don’t want different versions floating around, even if they differ only by an internal path.  In fact, if you’re doing a source-less deployment, then modifying the source like this during deployment isn’t even always possible.   Finally, building an installer for a CF app is more complexity than I need or want – especially in a language that makes everything else so easy.  I have personally built numerous non-CF, installer-based applications, but you can’t expect every CF developer to do the same.  In fact, I’d wager that it’s over the heads of a large portion of CF’s developer base.   Roland   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer - CMG, LLC Sent: Wednesday, May 04, 2005 12:05 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Basic component inheritance path question   But why? I mean... it's software, same as any other application software, its environment may need to be customized for it to run correctly. What if Macromedia took that attitude, saying they weren't going to provide parameter and config files for the JVM... it would die on the vine. It strikes me that choosing your development platform is a lot like choosing your friends... by incorporating either of them into your life you also choose to accept a certain level of responsibility for their strengths and weaknesses. If nothing else, there are social repercussions for befriending certain people... and there are some technological repercussions that come with choosing CF as a platform with which you work. Hence even Jrun has config files that manipulate its startup process, creating a customized (at least if need be) environment to support it, and the numerous other options they've built in over time in response to our requests. Maybe someone should write the CF equivalent of InstallShield, a framework for installing CF applications, and charge bajillions of dollars for it... in any case, there's a certain degree of responsibility to be taken for acknowledging and shoring up it's weaknesses while benefitting from its strengths. Or, to put it another way, why not light the candle of installers instead of cursing the darkness of broken types? Anyway... I don't mean to offend, but to offer a different perspective. Laterz, J On 5/3/05, Roland Collins <[EMAIL PROTECTED]> wrote: I hope I _never_ write an installer for a CF application.  "XCopy Deployment" is as complicated as I ever hope to have to get with CF.   Roland   -- --------------- ------------------------------------- Buy SQLSurveyor! http://www.web-relevant.com/sqlsurveyor Never make your developers open Enterprise Manager again. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org 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/cfcdev@cfczone.org