What I've done with clients (well, client, I've only had one that "left" me) who want to move is copy the site using httrack or similar, put it on a CD, and be done with it. I've also given them a copy of their specific web site content in .csv format.
On Mon, Feb 21, 2011 at 8:19 AM, Steve 'Cutter' Blades < cold.fus...@cutterscrossing.com> wrote: > > Though not always the case, my experience with MSOC sites is that you're > offering Software As A Service, where you retain all ownership of the > code and that is clearly stated within the contract with the client. > > Steve 'Cutter' Blades > Adobe Certified Expert > Advanced Macromedia ColdFusion MX 7 Developer > ____________ > http://blog.cutterscrossing.com > > > Co-Author "Learning Ext JS 3.2" Packt Publishing 2010 > > https://www.packtpub.com/learning-ext-js-3-2-for-building-dynamic-desktop-style-user-interfaces/book > > "The best way to predict the future is to help create it" > > > On 2/17/2011 12:21 PM, Robert Harrison wrote: > > From a technical standpoint you are on the right track... we do a > similar thing in that we use a standard framework and deploy that to the > sites we build, thus we use copies of the same codebase. It seems the > approach you are taking is to really use JUST ONE codebase to run all the > sites. > > > > Technically I can see the allure, and if this is for a company owned > group of web sites and they are all similar this can work. However, if this > is for sites you are deploying for clients, there are at least two places > where that can really cause some problems. There are: > > > > 1. Your relationship with the client changes and the client wants to > take the site and move. Now you are faced with either holding the client's > site hostage or giving away your multi-site base code framework (possibly > even to a competitor). Neither of those is an attractive option. > > > > 2. Also, assume one or more clients keeps coming back to you to make > adjustments and additions. Now your code is getting more and more mucked up > with custom-code exceptions. That's also not cool. Eventually that will > make your framework really difficult to manage and upgrade. > > > > If this is an in-house thing and you know the sites won't be moved and > you can control what's going in them somewhat, your approach is good. If > you're going to do this for separate clients, you should probably think > about building a framework you can copy, profile, and customize as needed. > > > > > > Robert B. Harrison > > Director of Interactive Services > > Austin& Williams > > 125 Kennedy Drive, Suite 100 > > Hauppauge NY 11788 > > P : 631.231.6600 Ext. 119 > > F : 631.434.7022 > > http://www.austin-williams.com > > > > Great advertising can't be either/or. It must be&. > > > > Plug in to our blog: A&W Unplugged > > http://www.austin-williams.com/unplugged > > > > -----Original Message----- > > From: Rick Faircloth [mailto:r...@whitestonemedia.com] > > Sent: Thursday, February 17, 2011 12:28 PM > > To: cf-talk > > Subject: Feedback on this approach to "many sites, one codebase" (MSOC) > > > > > > Hi, all... > > > > I've been tinkering around the edges with "many sites, one codebase" > (MSOC) for awhile and was interested in getting some feedback on an approach > I'm taking. > > > > The most basic part is that I use the domain name to determine variable > values for a site. > > > > I'll start with that. > > > > I use application.cfc to set up the following: > > > > <cfset this.name = "#cgi.server_name#"> > > > > Any issues with that? > > > > Then I have use the onApplicationStart cffunction to clear session and > application variables. > > > > Then I use the cgi.server_name, determined from the URL visited by a > user, of course, and run this query to get needed values for site variables > from a database: > > > > <cfquery name = "qGetApplicationVariables" > datasource="globalSiteManager"> > > > > select * > > from siteApplicationSettings > > where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > </cfquery> > > > > Then, I set site variables as follows: > > > > <cfset application.dsn = > "#qGetApplicationVariables.applicationDSN#'> > > etc... > > > > At this point, I'm entering all a site's variables into a database > manually, although if I continue with this approach, I'll develop an > automated solution. > > > > The site menu is determined also by values in a database for the site by > using code such as the following: > > > > <cfset application.calendar = > > '#qGetApplicationVariables.applicationCalendar#'> > > > > If the qGetApplicationVariables.applicationCalendar value is 'yes', then > the menu item is shown, if it's 'no', then the menu choice is not shown. > > > > The last piece of this approach is setting path variables, etc, for image > and document uploads, image paths, etc, with this type of code: > > > > <cfset application.userImagesPathAbsolute = > '#qGetApplicationVariables.applicationUserImagesPathAbsolute#'> > > etc. > > > > This seems to be working fine so far... speed is good, etc., but I'd like > to know, from those of you who have been down this road before, if I'm > heading for a show-stopping issue, or if this is a workable solution. > > > > And, I'm really not interested in frameworks...not at this point. > > > > Thanks for taking the time to read this and offer any feedback. > > I'm just ready to develop some applications that I can sell *more than > once*!! > > "Work smarter, not harder" approach. Watching people getting rich selling > apps for $.99, such as "Angry Birds", is just killing me. I thought, surely > there has got to be a better way to be a freelancer than "one-off" projects! > > > > Rick > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Order the Adobe Coldfusion Anthology now! http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342475 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
