Good points, Robert. Concerning point 1, a client wouldn't own a website that's based on a single codebase. I'd have to change my business model to accommodate the difference between a MSOC site and a custom site.
Concerning point 2, customization is definitely a concern. So far, I've just been using the MSOC approach for a site manager, so customization isn't a concern. But, I suppose if a client wanted a custom app built from the original codebase, I'd just export the codebase into a separate site for that client and made custom modifications. That does take us back to point 1 and the question of when does the newly created MSOC code and customizations become the property of the client. The idea behind the MSOC approach for me is to be able to sell sites much more cheaply. After all, I'm competing against GoDaddy's "Web Site Tonight" for $4.95. That's never been my approach, but by building sites that can be deployed very easily, I can basically sell the site for monthly hosting, if it's used "as is", in terms of functionality. Users would be able to select various styles by using stylesheets. This approach will allow me to more efficiently compete in the "trade site" market, where sites are targeted toward specific industries, such as Real Estate, Chambers of Commerce, etc. I've found that selling websites targeted toward specific businesses and industry is an easier sell than completely custom work. Rick -----Original Message----- From: Robert Harrison [mailto:[email protected]] Sent: Thursday, February 17, 2011 1:21 PM To: cf-talk Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) >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:[email protected]] 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:342412 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
