Yes, my perspective is that I would be offering SAAS. A client is not so much getting a site, as getting use of a customizable (mainly style) service.
-----Original Message----- From: Steve 'Cutter' Blades [mailto:[email protected]] Sent: Monday, February 21, 2011 8:20 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) 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-st yle-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:[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:342465 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
