Re: Feedback on this approach to "many sites, one codebase" (MSOC)
> > There are NO commercial sites in Australia that I know of that > habitually shut down for anything more than a minute or two EVER. > Habitually? Where are you getting this stuff from mate? Who said anything about habitually? Are you even reading the same posts stuff I'm posting? I'll bet you dollars to donuts that just about every major website in Australia that rolls out changes to the application core do it when the website is off for maintenance and not in the middle of some poor joker's session. ~| 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:342553 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
That wouldnt be a problem if you only did business in one country. But a LOT of web sites do business around the globe, when no matter what the time is, it's business hours in some part of the world. A VERY LARGE number of web sites of all sizes have no time down for maintenance, except on rare occasions. There are NO commercial sites in Australia that I know of that habitually shut down for anything more than a minute or two EVER. Cheers Mike Kear Windsor, NSW, Australia Adobe Certified Advanced ColdFusion Developer AFP Webworks http://afpwebworks.com ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month On Thu, Feb 24, 2011 at 1:45 AM, Michael Grant wrote: > > Really. Even banking sites come down for hours of maintenance. I suspect > whatever your sites are, your 24/7 with no exceptions is a policy vs. a true > necessity. Unless you are perhaps in the defence industry. > > Live code push? *shudders* > > On Wed, Feb 23, 2011 at 9:31 AM, Jane Williams > wrote: > >> >> Our sites run 24/7: we have no maintenance window that size. I bet I'm not >> the >> only one, either. >> > ~| 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:342552 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Yes, I used this method for a long time by putting code right into the CF codebase. I used a different datasource for the DB updates, one that allowed MODIFY / ALTER / CREATE, and then had the code test against existing DB structures to decide which changes needed to be made along with that set of code changes. Still always appreciated having those changes made in one DB, but it wouldn't have mattered much because all changes were managed in the same codebase. On 2/23/2011 3:46 PM, Brian Cain wrote: > I wrote a custom desktop application in VB to update all my databases at one > time. Using SQL scripting this can be easily managed. When I am ready to > roll out a change that requires a DB update, I can do it in real time, with > minimal service interruption, and without taking the sites offline. It has > not failed me yet, and I have been doing it that way for over 6 years. > > > ~| 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:342539 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Granted most of my changes are minor like updating a stored procedure or view or adding a column. I also run them on a test database first. Updates that may have a major impact on a table with millions of records, would never be done while the sites are up, but regular minor changes and fixes by nature do not have as wide an impact as major updates and fixes. If you are making major changes you would definitely need to to some testing and have a well planned implementation strategy. ~| 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:342537 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
That may be. I have a lot of friends who haven't been busted driving after a few glasses of wine. By your reasoning since they haven't been busted it must not be a bad idea. On Wed, Feb 23, 2011 at 3:46 PM, Brian Cain wrote: > > I wrote a custom desktop application in VB to update all my databases at > one > time. Using SQL scripting this can be easily managed. When I am ready to > roll out a change that requires a DB update, I can do it in real time, with > minimal service interruption, and without taking the sites offline. It has > not failed me yet, and I have been doing it that way for over 6 years. > > > ~| 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:342536 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I wrote a custom desktop application in VB to update all my databases at one time. Using SQL scripting this can be easily managed. When I am ready to roll out a change that requires a DB update, I can do it in real time, with minimal service interruption, and without taking the sites offline. It has not failed me yet, and I have been doing it that way for over 6 years. ~| 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:342535 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
> > > Taking the system down for an entire hour, without warning, would not be > acceptable. Who said anything about without warning? How can you possibly have gotten that from what I said? We're talking about making code changes to a large multi-user application, not some casual css change. Of course you would notify your clientele ahead of time. I had no idea e-Learning ranked above international commerce for uptime necessity. ~| 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:342522 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Tell my managers I have been in the defence industry, but not at the moment. We supply e-learning to customers who need/expect to access it more or less 24/7 - they work shifts. Taking the system down for an entire hour, without warning, would not be acceptable. Five minutes once a week, yes, but any more would be for a big upgrade, not just regular maintenance. Still, if a big upgrade is what we're talking about, then we inform them, give them a weeks notice, and take it down for the day. I'm not doing go-live and full testing in my sleep. - Original Message From: Michael Grant To: cf-talk Sent: Wed, 23 February, 2011 14:45:15 Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) Really. Even banking sites come down for hours of maintenance. I suspect whatever your sites are, your 24/7 with no exceptions is a policy vs. a true necessity. Unless you are perhaps in the defence industry. Live code push? *shudders* On Wed, Feb 23, 2011 at 9:31 AM, Jane Williams wrote: > > Our sites run 24/7: we have no maintenance window that size. I bet I'm not > the > only one, either. > > > > - Original Message > From: Michael Grant > To: cf-talk > Sent: Wed, 23 February, 2011 14:21:31 > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > Only if you roll your changes out while the site is live rather than during > a maintenance window. > Take the site down for an hour at 4am, push your code live and run your db > updating scripts on each db. > It shouldn't really be too big a deal. ~| 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:342521 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Really. Even banking sites come down for hours of maintenance. I suspect whatever your sites are, your 24/7 with no exceptions is a policy vs. a true necessity. Unless you are perhaps in the defence industry. Live code push? *shudders* On Wed, Feb 23, 2011 at 9:31 AM, Jane Williams wrote: > > Our sites run 24/7: we have no maintenance window that size. I bet I'm not > the > only one, either. > > > > - Original Message > From: Michael Grant > To: cf-talk > Sent: Wed, 23 February, 2011 14:21:31 > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > Only if you roll your changes out while the site is live rather than during > a maintenance window. > Take the site down for an hour at 4am, push your code live and run your db > updating scripts on each db. > It shouldn't really be too big a deal. > > On Wed, Feb 23, 2011 at 7:33 AM, Jason Fisher wrote: > > > > > The big caveat I will give about have multiple databases with > multi-tenant > > code is that any change to the shared code has to be reflected in every > > single database simultaneously. And that's a challenge and a half. > > > > -------- > > > > From: "Rick Faircloth" > > Sent: Tuesday, February 22, 2011 10:58 PM > > To: "cf-talk" > > Subject: RE: Feedback on this approach to "many sites, one codebase" > > (MSOC) > > > > I can see both sides on this one very clearly. > > > > To this point, all I've ever done is develop custom > > applications and websites. I haven't sold the exact same > > site in 10 or so years of development! > > > > However, I really want to get away from working > > just one-on-one with clients. They can be a real pain. > > Some are just downright ignorant and impossible to work with. > > (You can tell I've had a couple of bad experiences lately... ;o) > > > > I'm want to move into developing sites for specific uses, such > > as for recreation departments or real estate agents and brokers, etc., > > and have them sign up for the site online, choose their template, > > put in their content, and, after a free trial period, they pay > > their money. If they need support, they can email me. > > > > If they want functional customization, I'll build a custom function for a > > client, > > charge them for it, then make that function available to anyone > > else using my "SAAS" sites. The customers will never own the sites > > and never have the opportunity to "take the code" elsewhere. > > > > If they want cosmetic or style customization, I can do that > > and charge them for it. It will still remain my site and not > > the client's site. > > > > I'll still build custom apps along the way, I'm sure, but I'd > > like to start making my work on an app/site pay more than one time. > > > > However, like you Matt, I may end up going back to individual > > customizations, if things don't work out so well on the SAAS front. > > I do have some clients who always insist on being absolutely unique > > and want to have the "best" site. To those who want to be absolutely > > unique, I can sell the template for a few thousand or whatever amount, > > and they'll have exclusive rights to use that template, but they > > still won't own it. Soon as they stop paying, the template goes > > back into the fold. > > > > I just want to test this approach and see if I can make it work. > > > > Rick > > > > PS - when it comes to the database, I'm leaning towards a different > > database for each client. I'd hate to have problems with a client's > > data and have to parse through everyone else's data to see what > > the problem is. Of course, I do have some "common data" databases > > that everyone would share...local area info, etc. But I'm currently > > still using distinct databases for client-specific data. > > > > -Original Message- > > From: Matt Robertson [mailto:websitema...@gmail.com] > > Sent: Tuesday, February 22, 2011 1:02 PM > > To: cf-talk > > Subject: Re: Feedback on this approach to "many sites, one codebase" > > (MSOC) > > > > Even though my own CMS can handle multiple sites running off of a > > single installation, I don't run it that way. The points brought up > > about clients wanting individual customizations and portability fit my > > situation. I u
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Our sites run 24/7: we have no maintenance window that size. I bet I'm not the only one, either. - Original Message From: Michael Grant To: cf-talk Sent: Wed, 23 February, 2011 14:21:31 Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) Only if you roll your changes out while the site is live rather than during a maintenance window. Take the site down for an hour at 4am, push your code live and run your db updating scripts on each db. It shouldn't really be too big a deal. On Wed, Feb 23, 2011 at 7:33 AM, Jason Fisher wrote: > > The big caveat I will give about have multiple databases with multi-tenant > code is that any change to the shared code has to be reflected in every > single database simultaneously. And that's a challenge and a half. > > > > From: "Rick Faircloth" > Sent: Tuesday, February 22, 2011 10:58 PM > To: "cf-talk" > Subject: RE: Feedback on this approach to "many sites, one codebase" > (MSOC) > > I can see both sides on this one very clearly. > > To this point, all I've ever done is develop custom > applications and websites. I haven't sold the exact same > site in 10 or so years of development! > > However, I really want to get away from working > just one-on-one with clients. They can be a real pain. > Some are just downright ignorant and impossible to work with. > (You can tell I've had a couple of bad experiences lately... ;o) > > I'm want to move into developing sites for specific uses, such > as for recreation departments or real estate agents and brokers, etc., > and have them sign up for the site online, choose their template, > put in their content, and, after a free trial period, they pay > their money. If they need support, they can email me. > > If they want functional customization, I'll build a custom function for a > client, > charge them for it, then make that function available to anyone > else using my "SAAS" sites. The customers will never own the sites > and never have the opportunity to "take the code" elsewhere. > > If they want cosmetic or style customization, I can do that > and charge them for it. It will still remain my site and not > the client's site. > > I'll still build custom apps along the way, I'm sure, but I'd > like to start making my work on an app/site pay more than one time. > > However, like you Matt, I may end up going back to individual > customizations, if things don't work out so well on the SAAS front. > I do have some clients who always insist on being absolutely unique > and want to have the "best" site. To those who want to be absolutely > unique, I can sell the template for a few thousand or whatever amount, > and they'll have exclusive rights to use that template, but they > still won't own it. Soon as they stop paying, the template goes > back into the fold. > > I just want to test this approach and see if I can make it work. > > Rick > > PS - when it comes to the database, I'm leaning towards a different > database for each client. I'd hate to have problems with a client's > data and have to parse through everyone else's data to see what > the problem is. Of course, I do have some "common data" databases > that everyone would share...local area info, etc. But I'm currently > still using distinct databases for client-specific data. > > -Original Message- > From: Matt Robertson [mailto:websitema...@gmail.com] > Sent: Tuesday, February 22, 2011 1:02 PM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" > (MSOC) > > Even though my own CMS can handle multiple sites running off of a > single installation, I don't run it that way. The points brought up > about clients wanting individual customizations and portability fit my > situation. I understand if you are offering software-as-a-service > things change, but for me this turned out to be enough of a headache > that I reverted to separate installs and have never regretted it. If > a customer wants an upgrade, they pay me an hour or two individually > to make that happen. If they want a specific feature that I don't > want to fold into the overall codebase, I can do it - and earn the > money for doing it - without worrying about consequences on 40 other > web sites on the server. But thats a business decision and not > coding. Mentioned just as food for thought. > > For sites for my own company, where presently we have about 36 up and > running and will be at around 60 when we are done, we *do* share
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Only if you roll your changes out while the site is live rather than during a maintenance window. Take the site down for an hour at 4am, push your code live and run your db updating scripts on each db. It shouldn't really be too big a deal. On Wed, Feb 23, 2011 at 7:33 AM, Jason Fisher wrote: > > The big caveat I will give about have multiple databases with multi-tenant > code is that any change to the shared code has to be reflected in every > single database simultaneously. And that's a challenge and a half. > > > > From: "Rick Faircloth" > Sent: Tuesday, February 22, 2011 10:58 PM > To: "cf-talk" > Subject: RE: Feedback on this approach to "many sites, one codebase" > (MSOC) > > I can see both sides on this one very clearly. > > To this point, all I've ever done is develop custom > applications and websites. I haven't sold the exact same > site in 10 or so years of development! > > However, I really want to get away from working > just one-on-one with clients. They can be a real pain. > Some are just downright ignorant and impossible to work with. > (You can tell I've had a couple of bad experiences lately... ;o) > > I'm want to move into developing sites for specific uses, such > as for recreation departments or real estate agents and brokers, etc., > and have them sign up for the site online, choose their template, > put in their content, and, after a free trial period, they pay > their money. If they need support, they can email me. > > If they want functional customization, I'll build a custom function for a > client, > charge them for it, then make that function available to anyone > else using my "SAAS" sites. The customers will never own the sites > and never have the opportunity to "take the code" elsewhere. > > If they want cosmetic or style customization, I can do that > and charge them for it. It will still remain my site and not > the client's site. > > I'll still build custom apps along the way, I'm sure, but I'd > like to start making my work on an app/site pay more than one time. > > However, like you Matt, I may end up going back to individual > customizations, if things don't work out so well on the SAAS front. > I do have some clients who always insist on being absolutely unique > and want to have the "best" site. To those who want to be absolutely > unique, I can sell the template for a few thousand or whatever amount, > and they'll have exclusive rights to use that template, but they > still won't own it. Soon as they stop paying, the template goes > back into the fold. > > I just want to test this approach and see if I can make it work. > > Rick > > PS - when it comes to the database, I'm leaning towards a different > database for each client. I'd hate to have problems with a client's > data and have to parse through everyone else's data to see what > the problem is. Of course, I do have some "common data" databases > that everyone would share...local area info, etc. But I'm currently > still using distinct databases for client-specific data. > > -Original Message- > From: Matt Robertson [mailto:websitema...@gmail.com] > Sent: Tuesday, February 22, 2011 1:02 PM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" > (MSOC) > > Even though my own CMS can handle multiple sites running off of a > single installation, I don't run it that way. The points brought up > about clients wanting individual customizations and portability fit my > situation. I understand if you are offering software-as-a-service > things change, but for me this turned out to be enough of a headache > that I reverted to separate installs and have never regretted it. If > a customer wants an upgrade, they pay me an hour or two individually > to make that happen. If they want a specific feature that I don't > want to fold into the overall codebase, I can do it - and earn the > money for doing it - without worrying about consequences on 40 other > web sites on the server. But thats a business decision and not > coding. Mentioned just as food for thought. > > For sites for my own company, where presently we have about 36 up and > running and will be at around 60 when we are done, we *do* share a > single codebase. There are no special mappings. Each site has an > Application.cfm that looks like this: > > request.appName="AR_060110_1033"; > request.rootFolder="ARDotCom/"; > request.FQDN="www.mysiteAR.com"; > > > > The c
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
That's true...definitely something to take into consideration. -Original Message- From: Jason Fisher [mailto:ja...@wanax.com] Sent: Wednesday, February 23, 2011 7:34 AM To: cf-talk Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) The big caveat I will give about have multiple databases with multi-tenant code is that any change to the shared code has to be reflected in every single database simultaneously. And that's a challenge and a half. ~| 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:342515 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
The big caveat I will give about have multiple databases with multi-tenant code is that any change to the shared code has to be reflected in every single database simultaneously. And that's a challenge and a half. From: "Rick Faircloth" Sent: Tuesday, February 22, 2011 10:58 PM To: "cf-talk" Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) I can see both sides on this one very clearly. To this point, all I've ever done is develop custom applications and websites. I haven't sold the exact same site in 10 or so years of development! However, I really want to get away from working just one-on-one with clients. They can be a real pain. Some are just downright ignorant and impossible to work with. (You can tell I've had a couple of bad experiences lately... ;o) I'm want to move into developing sites for specific uses, such as for recreation departments or real estate agents and brokers, etc., and have them sign up for the site online, choose their template, put in their content, and, after a free trial period, they pay their money. If they need support, they can email me. If they want functional customization, I'll build a custom function for a client, charge them for it, then make that function available to anyone else using my "SAAS" sites. The customers will never own the sites and never have the opportunity to "take the code" elsewhere. If they want cosmetic or style customization, I can do that and charge them for it. It will still remain my site and not the client's site. I'll still build custom apps along the way, I'm sure, but I'd like to start making my work on an app/site pay more than one time. However, like you Matt, I may end up going back to individual customizations, if things don't work out so well on the SAAS front. I do have some clients who always insist on being absolutely unique and want to have the "best" site. To those who want to be absolutely unique, I can sell the template for a few thousand or whatever amount, and they'll have exclusive rights to use that template, but they still won't own it. Soon as they stop paying, the template goes back into the fold. I just want to test this approach and see if I can make it work. Rick PS - when it comes to the database, I'm leaning towards a different database for each client. I'd hate to have problems with a client's data and have to parse through everyone else's data to see what the problem is. Of course, I do have some "common data" databases that everyone would share...local area info, etc. But I'm currently still using distinct databases for client-specific data. -----Original Message- From: Matt Robertson [mailto:websitema...@gmail.com] Sent: Tuesday, February 22, 2011 1:02 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) Even though my own CMS can handle multiple sites running off of a single installation, I don't run it that way. The points brought up about clients wanting individual customizations and portability fit my situation. I understand if you are offering software-as-a-service things change, but for me this turned out to be enough of a headache that I reverted to separate installs and have never regretted it. If a customer wants an upgrade, they pay me an hour or two individually to make that happen. If they want a specific feature that I don't want to fold into the overall codebase, I can do it - and earn the money for doing it - without worrying about consequences on 40 other web sites on the server. But thats a business decision and not coding. Mentioned just as food for thought. For sites for my own company, where presently we have about 36 up and running and will be at around 60 when we are done, we *do* share a single codebase. There are no special mappings. Each site has an Application.cfm that looks like this: request.appName="AR_060110_1033"; request.rootFolder="ARDotCom/"; request.FQDN="www.mysiteAR.com"; The common file has some server vars too: server.BaseRoot="C:/foo/bar/sites/"; server.dsn= etc. etc. blah blah And thats enough - along with more code in the common "Application.cfm" - to set up absolute and relative paths to the files I have located in the common-use folder. Every site has its own independent application scope. I've opted to set the app name manually so I can reset session and app vars if need be... a rare occurrence but its nice to have the option available. The root of this web site is a root folder in a discrete IIS web site and, since CF has no trouble recursing back up beyond a web root insofar as physical paths go, the /common/ folder is not accessible from the web, but it is from CF.
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
I can see both sides on this one very clearly. To this point, all I've ever done is develop custom applications and websites. I haven't sold the exact same site in 10 or so years of development! However, I really want to get away from working just one-on-one with clients. They can be a real pain. Some are just downright ignorant and impossible to work with. (You can tell I've had a couple of bad experiences lately... ;o) I'm want to move into developing sites for specific uses, such as for recreation departments or real estate agents and brokers, etc., and have them sign up for the site online, choose their template, put in their content, and, after a free trial period, they pay their money. If they need support, they can email me. If they want functional customization, I'll build a custom function for a client, charge them for it, then make that function available to anyone else using my "SAAS" sites. The customers will never own the sites and never have the opportunity to "take the code" elsewhere. If they want cosmetic or style customization, I can do that and charge them for it. It will still remain my site and not the client's site. I'll still build custom apps along the way, I'm sure, but I'd like to start making my work on an app/site pay more than one time. However, like you Matt, I may end up going back to individual customizations, if things don't work out so well on the SAAS front. I do have some clients who always insist on being absolutely unique and want to have the "best" site. To those who want to be absolutely unique, I can sell the template for a few thousand or whatever amount, and they'll have exclusive rights to use that template, but they still won't own it. Soon as they stop paying, the template goes back into the fold. I just want to test this approach and see if I can make it work. Rick PS - when it comes to the database, I'm leaning towards a different database for each client. I'd hate to have problems with a client's data and have to parse through everyone else's data to see what the problem is. Of course, I do have some "common data" databases that everyone would share...local area info, etc. But I'm currently still using distinct databases for client-specific data. -Original Message- From: Matt Robertson [mailto:websitema...@gmail.com] Sent: Tuesday, February 22, 2011 1:02 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) Even though my own CMS can handle multiple sites running off of a single installation, I don't run it that way. The points brought up about clients wanting individual customizations and portability fit my situation. I understand if you are offering software-as-a-service things change, but for me this turned out to be enough of a headache that I reverted to separate installs and have never regretted it. If a customer wants an upgrade, they pay me an hour or two individually to make that happen. If they want a specific feature that I don't want to fold into the overall codebase, I can do it - and earn the money for doing it - without worrying about consequences on 40 other web sites on the server. But thats a business decision and not coding. Mentioned just as food for thought. For sites for my own company, where presently we have about 36 up and running and will be at around 60 when we are done, we *do* share a single codebase. There are no special mappings. Each site has an Application.cfm that looks like this: request.appName="AR_060110_1033"; request.rootFolder="ARDotCom/"; request.FQDN="www.mysiteAR.com"; The common file has some server vars too: server.BaseRoot="C:/foo/bar/sites/"; server.dsn= etc. etc. blah blah And thats enough - along with more code in the common "Application.cfm" - to set up absolute and relative paths to the files I have located in the common-use folder. Every site has its own independent application scope. I've opted to set the app name manually so I can reset session and app vars if need be... a rare occurrence but its nice to have the option available. The root of this web site is a root folder in a discrete IIS web site and, since CF has no trouble recursing back up beyond a web root insofar as physical paths go, the /common/ folder is not accessible from the web, but it is from CF. Very simple to set up. ~| 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:342503 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
In the application scope... but you have a structure, such as: application.settings.sites["CHR"]["config"]["adminEmail"] As I said, it works great for us. We don't have a "tear off" site structure, and a client can't ask for the code, since it would be impossible to replicate due to the business we provide, so I imagine we'd have to tweak things if that were a requirement. On Tue, Feb 22, 2011 at 4:05 PM, Steve 'Cutter' Blades < cold.fus...@cutterscrossing.com> wrote: > > I'm curious how this is handled in some cases. A single application > would have a smaller memory footprint on the server, but I've always > placed site specific variables in the application scope, keeping > sessions much smaller and reducing overall memory overhead. Yes, > reinitializing applications can be a bear sometimes, but the savings in > memory overhead in high traffic apps is worth the hardship. > > 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/22/2011 1:30 PM, Brian Meloche wrote: > > I'm late to the thread, but like Eric and Sean have indicated, having all > > domains under the same application name is the way to go. We've got a > > big multi-tenant application here (several hundred thousand lines of > > code) designed that way and it works great. Reinitializing an application > is > > quick and easy (taking servers out of the farm before doing it, of > course) - > > seconds, not minutes, and that is for all domains at a time, not for each > > one at a time. That's all because of how it's designed. > > > > I was hoping to speak on the same subject at CFObjective, but Sean got > > picked to speak over me. :-( > > > > On Tue, Feb 22, 2011 at 1:01 PM, Matt Robertson >wrote: > > > >> Even though my own CMS can handle multiple sites running off of a > >> single installation, I don't run it that way. The points brought up > >> about clients wanting individual customizations and portability fit my > >> situation. I understand if you are offering software-as-a-service > >> things change, but for me this turned out to be enough of a headache > >> that I reverted to separate installs and have never regretted it. If > >> a customer wants an upgrade, they pay me an hour or two individually > >> to make that happen. If they want a specific feature that I don't > >> want to fold into the overall codebase, I can do it - and earn the > >> money for doing it - without worrying about consequences on 40 other > >> web sites on the server. But thats a business decision and not > >> coding. Mentioned just as food for thought. > >> > >> For sites for my own company, where presently we have about 36 up and > >> running and will be at around 60 when we are done, we *do* share a > >> single codebase. There are no special mappings. Each site has an > >> Application.cfm that looks like this: > >> > >> request.appName="AR_060110_1033"; > >> request.rootFolder="ARDotCom/"; > >> request.FQDN="www.mysiteAR.com"; > >> > >> > >> > >> The common file has some server vars too: > >> > >> server.BaseRoot="C:/foo/bar/sites/"; > >> server.dsn= etc. etc. blah blah > >> > >> And thats enough - along with more code in the common > >> "Application.cfm" - to set up absolute and relative paths to the files > >> I have located in the common-use folder. Every site has its own > >> independent application scope. > >> > >> I've opted to set the app name manually so I can reset session and app > >> vars if need be... a rare occurrence but its nice to have the option > >> available. > >> > >> The root of this web site is a root folder in a discrete IIS web site > >> and, since CF has no trouble recursing back up beyond a web root > >> insofar as physical paths go, the /common/ folder is not accessible > >> from the web, but it is from CF. Very simple to set up. > >> > >> -- > >> --m@Robertson-- > >> Janitor, The Robertson Team > >> mysecretbase.com > >> > >> > > > > ~| 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:342488 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I'm curious how this is handled in some cases. A single application would have a smaller memory footprint on the server, but I've always placed site specific variables in the application scope, keeping sessions much smaller and reducing overall memory overhead. Yes, reinitializing applications can be a bear sometimes, but the savings in memory overhead in high traffic apps is worth the hardship. 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/22/2011 1:30 PM, Brian Meloche wrote: > I'm late to the thread, but like Eric and Sean have indicated, having all > domains under the same application name is the way to go. We've got a > big multi-tenant application here (several hundred thousand lines of > code) designed that way and it works great. Reinitializing an application is > quick and easy (taking servers out of the farm before doing it, of course) - > seconds, not minutes, and that is for all domains at a time, not for each > one at a time. That's all because of how it's designed. > > I was hoping to speak on the same subject at CFObjective, but Sean got > picked to speak over me. :-( > > On Tue, Feb 22, 2011 at 1:01 PM, Matt Robertsonwrote: > >> Even though my own CMS can handle multiple sites running off of a >> single installation, I don't run it that way. The points brought up >> about clients wanting individual customizations and portability fit my >> situation. I understand if you are offering software-as-a-service >> things change, but for me this turned out to be enough of a headache >> that I reverted to separate installs and have never regretted it. If >> a customer wants an upgrade, they pay me an hour or two individually >> to make that happen. If they want a specific feature that I don't >> want to fold into the overall codebase, I can do it - and earn the >> money for doing it - without worrying about consequences on 40 other >> web sites on the server. But thats a business decision and not >> coding. Mentioned just as food for thought. >> >> For sites for my own company, where presently we have about 36 up and >> running and will be at around 60 when we are done, we *do* share a >> single codebase. There are no special mappings. Each site has an >> Application.cfm that looks like this: >> >> request.appName="AR_060110_1033"; >> request.rootFolder="ARDotCom/"; >> request.FQDN="www.mysiteAR.com"; >> >> >> >> The common file has some server vars too: >> >> server.BaseRoot="C:/foo/bar/sites/"; >> server.dsn= etc. etc. blah blah >> >> And thats enough - along with more code in the common >> "Application.cfm" - to set up absolute and relative paths to the files >> I have located in the common-use folder. Every site has its own >> independent application scope. >> >> I've opted to set the app name manually so I can reset session and app >> vars if need be... a rare occurrence but its nice to have the option >> available. >> >> The root of this web site is a root folder in a discrete IIS web site >> and, since CF has no trouble recursing back up beyond a web root >> insofar as physical paths go, the /common/ folder is not accessible >> from the web, but it is from CF. Very simple to set up. >> >> -- >> --m@Robertson-- >> Janitor, The Robertson Team >> mysecretbase.com >> >> > ~| 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:342487 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I'm late to the thread, but like Eric and Sean have indicated, having all domains under the same application name is the way to go. We've got a big multi-tenant application here (several hundred thousand lines of code) designed that way and it works great. Reinitializing an application is quick and easy (taking servers out of the farm before doing it, of course) - seconds, not minutes, and that is for all domains at a time, not for each one at a time. That's all because of how it's designed. I was hoping to speak on the same subject at CFObjective, but Sean got picked to speak over me. :-( On Tue, Feb 22, 2011 at 1:01 PM, Matt Robertson wrote: > > Even though my own CMS can handle multiple sites running off of a > single installation, I don't run it that way. The points brought up > about clients wanting individual customizations and portability fit my > situation. I understand if you are offering software-as-a-service > things change, but for me this turned out to be enough of a headache > that I reverted to separate installs and have never regretted it. If > a customer wants an upgrade, they pay me an hour or two individually > to make that happen. If they want a specific feature that I don't > want to fold into the overall codebase, I can do it - and earn the > money for doing it - without worrying about consequences on 40 other > web sites on the server. But thats a business decision and not > coding. Mentioned just as food for thought. > > For sites for my own company, where presently we have about 36 up and > running and will be at around 60 when we are done, we *do* share a > single codebase. There are no special mappings. Each site has an > Application.cfm that looks like this: > > request.appName="AR_060110_1033"; > request.rootFolder="ARDotCom/"; > request.FQDN="www.mysiteAR.com"; > > > > The common file has some server vars too: > > server.BaseRoot="C:/foo/bar/sites/"; > server.dsn= etc. etc. blah blah > > And thats enough - along with more code in the common > "Application.cfm" - to set up absolute and relative paths to the files > I have located in the common-use folder. Every site has its own > independent application scope. > > I've opted to set the app name manually so I can reset session and app > vars if need be... a rare occurrence but its nice to have the option > available. > > The root of this web site is a root folder in a discrete IIS web site > and, since CF has no trouble recursing back up beyond a web root > insofar as physical paths go, the /common/ folder is not accessible > from the web, but it is from CF. Very simple to set up. > > -- > --m@Robertson-- > Janitor, The Robertson Team > mysecretbase.com > > ~| 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:342484 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Even though my own CMS can handle multiple sites running off of a single installation, I don't run it that way. The points brought up about clients wanting individual customizations and portability fit my situation. I understand if you are offering software-as-a-service things change, but for me this turned out to be enough of a headache that I reverted to separate installs and have never regretted it. If a customer wants an upgrade, they pay me an hour or two individually to make that happen. If they want a specific feature that I don't want to fold into the overall codebase, I can do it - and earn the money for doing it - without worrying about consequences on 40 other web sites on the server. But thats a business decision and not coding. Mentioned just as food for thought. For sites for my own company, where presently we have about 36 up and running and will be at around 60 when we are done, we *do* share a single codebase. There are no special mappings. Each site has an Application.cfm that looks like this: request.appName="AR_060110_1033"; request.rootFolder="ARDotCom/"; request.FQDN="www.mysiteAR.com"; The common file has some server vars too: server.BaseRoot="C:/foo/bar/sites/"; server.dsn= etc. etc. blah blah And thats enough - along with more code in the common "Application.cfm" - to set up absolute and relative paths to the files I have located in the common-use folder. Every site has its own independent application scope. I've opted to set the app name manually so I can reset session and app vars if need be... a rare occurrence but its nice to have the option available. The root of this web site is a root folder in a discrete IIS web site and, since CF has no trouble recursing back up beyond a web root insofar as physical paths go, the /common/ folder is not accessible from the web, but it is from CF. Very simple to set up. -- --m@Robertson-- Janitor, The Robertson Team mysecretbase.com ~| 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:342481 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
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: > > > > > > > > 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: > > > > datasource="globalSiteManager"> > > > > select * > > fromsiteApplicationSettings > > where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > > > > > Then, I set site variables as follows: > > > > "#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 solu
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Typically I'll use Virtual Directories (or Alias in Apache) for this, to
ref the SiteSpecific folder, and use ExpandPath("/SiteSpecific") to
build out absolute paths for internal app use. No db interaction
required, pathing automatically changes if the server config changes.
(Not sure how this works in an S3 scenario, as I haven't had the opp to
try yet).
FileWrite(ExpandPath("/SiteSpecific") & "\" & APPLICATION.site.siteId &
"\assets\documents\nav.xml",REQUEST.navigation);
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"
~|
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:342471
Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
Generally I have a 'sites' table in my db with some basic site level info, and a separate 'sitesUrls' table that then foreign keys to the sites table. My siteId is the autogenerated key for that site's record in the sites table. 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/21/2011 10:38 AM, Rick Faircloth wrote: > Sounds like a good idea. > > So, to implement your approach, I would add a siteID into the database > info linked to a domain name? Just an abstract siteID as the main > identifier for the site variables, as opposed to using the site > domain name, right? > > Rick > > -Original Message- > From: Steve 'Cutter' Blades [mailto:cold.fus...@cutterscrossing.com] > Sent: Monday, February 21, 2011 8:13 AM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > I tend to use a siteId, based upon the query return. I can then reuse > that ID for things like the folder name of a SiteSpecific media/assets > folder. If the site url changes, the siteId does not, eliminating future > heartaches. > > 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 11:28 AM, Rick Faircloth wrote: >> 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: >> >> >> >> 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: >> >> >> >> select * >> fromsiteApplicationSettings >> where (select strcmp(siteName, '#cgi.server_name#')) = -1 >> >> >> >> Then, I set site variables as follows: >> >> "#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: >> >> > '#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: >> >> > '#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:342469 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Do you using IIS mappings or virtual directories for this structure? Or perhaps, CF mappings to implement this? -Original Message- From: Steve 'Cutter' Blades [mailto:cold.fus...@cutterscrossing.com] Sent: Monday, February 21, 2011 8:33 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) I'm going to talk more about file structure in a post on my MSOC series, following my current discussions breaking down application event handlers. My experience shows having one base path to a SiteSpecific root: \\(some drive share\SiteSpecific Then I use a subfolder for each site: \\(some drive share\SiteSpecific\225 \\(some drive share\SiteSpecific\256 I then place all assets for a site in their SiteSpecific folder, and use a consistent naming convention for each: \\(some drive share)\SiteSpecific\(siteId)\assets\ \\(some drive share)\SiteSpecific\(siteId)\assets\images \\(some drive share)\SiteSpecific\(siteId)\assets\css \\(some drive share)\SiteSpecific\(siteId)\assets\scripts \\(some drive share)\SiteSpecific\(siteId)\assets\documents I also have a specific set of directories for app specific assets that are not adjustable by end clients: \wwwroot\assets\ \wwwroot\assets\images \wwwroot\assets\images\icons \wwwroot\assets\css \wwwroot\assets\scripts This way, if I decide to change my SiteSpecific root (like moving it all into S3), it's a matter of changing one variable (the site specific root) to affect all sites. 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:31 PM, Rick Faircloth wrote: > Thanks, Brian... good info on the subdomains. > > Re: virtual directories... I was about to say "yes", but after > looking at the directories of the sites involving the > "global site manager", I realized I didn't have any virtual IIS > directories in users' sites. (I have them for other purposes > unrelated to this "global site manager"...) > > I've been setting full http and absolute paths for image and > document handling, etc. using variables and values from the database. > > One reason for this is my setup for my development cycle from > the local site, to an online development site, to the full production site. > > I've been using this code for establishing which type of site the > "global site manager" should be working with: > > > > '#qGetApplicationVariables.applicationLocalhostDomain#'/> > '#qGetApplicationVariables.applicationLocalhostUserImagesPathHTTP#'/> > '#qGetApplicationVariables.applicationLocalhostUserImagesPathAbsolute#'/> > '#qGetApplicationVariables.applicationLocalhostUserDocumentsPathHTTP#'/> > '#qGetApplicationVariables.applicationLocalhostUserDocumentsPathAbsolute#'/> > > > > '#qGetApplicationVariables.applicationDevelopmentDomain#'/> > '#qGetApplicationVariables.applicationDevelopmentUserImagesPathHTTP#'/> > '#qGetApplicationVariables.applicationDevelopmentUserImagesPathAbsolute#'/> > '#qGetApplicationVariables.applicationDevelopmentUserDocumentsPathHTTP#'/> > ='#qGetApplicationVariables.applicationDevelopmentUserDocumentsPathAbsolute# > ' /> > > > > '#qGetApplicationVariables.applicationProductionDomain#'/> > '#qGetApplicationVariables.applicationProductionUserImagesPathHTTP#'/> > '#qGetApplicationVariables.applicationProductionUserImagesPathAbsolute#'/> > '#qGetApplicationVariables.applicationProductionUserDocumentsPathHTTP#'/> > '#qGetApplicationVariables.applicationProductionUserDocumentsPathAbsolute#' > /> > > > > I put all my development sites for clients under the > domain whitestonemedia.com as a subdomain. This lets me > work on whatever level; local, online-development, or production, > that I want just by choosing a different domain name in the browser. > > ie... > > http://localhost/inetpub/webroot/clientSite
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
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:cold.fus...@cutterscrossing.com] 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: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: > > > > 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: > > > > select * > fromsiteApplicationSettings > where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > > 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
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Sounds like a good idea. So, to implement your approach, I would add a siteID into the database info linked to a domain name? Just an abstract siteID as the main identifier for the site variables, as opposed to using the site domain name, right? Rick -Original Message- From: Steve 'Cutter' Blades [mailto:cold.fus...@cutterscrossing.com] Sent: Monday, February 21, 2011 8:13 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) I tend to use a siteId, based upon the query return. I can then reuse that ID for things like the folder name of a SiteSpecific media/assets folder. If the site url changes, the siteId does not, eliminating future heartaches. 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 11:28 AM, Rick Faircloth wrote: > 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: > > > > 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: > > > > select * > fromsiteApplicationSettings > where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > 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:342464 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I'm going to talk more about file structure in a post on my MSOC series, following my current discussions breaking down application event handlers. My experience shows having one base path to a SiteSpecific root: \\(some drive share\SiteSpecific Then I use a subfolder for each site: \\(some drive share\SiteSpecific\225 \\(some drive share\SiteSpecific\256 I then place all assets for a site in their SiteSpecific folder, and use a consistent naming convention for each: \\(some drive share)\SiteSpecific\(siteId)\assets\ \\(some drive share)\SiteSpecific\(siteId)\assets\images \\(some drive share)\SiteSpecific\(siteId)\assets\css \\(some drive share)\SiteSpecific\(siteId)\assets\scripts \\(some drive share)\SiteSpecific\(siteId)\assets\documents I also have a specific set of directories for app specific assets that are not adjustable by end clients: \wwwroot\assets\ \wwwroot\assets\images \wwwroot\assets\images\icons \wwwroot\assets\css \wwwroot\assets\scripts This way, if I decide to change my SiteSpecific root (like moving it all into S3), it's a matter of changing one variable (the site specific root) to affect all sites. 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:31 PM, Rick Faircloth wrote: > Thanks, Brian... good info on the subdomains. > > Re: virtual directories... I was about to say "yes", but after > looking at the directories of the sites involving the > "global site manager", I realized I didn't have any virtual IIS > directories in users' sites. (I have them for other purposes > unrelated to this "global site manager"...) > > I've been setting full http and absolute paths for image and > document handling, etc. using variables and values from the database. > > One reason for this is my setup for my development cycle from > the local site, to an online development site, to the full production site. > > I've been using this code for establishing which type of site the > "global site manager" should be working with: > > > > '#qGetApplicationVariables.applicationLocalhostDomain#'/> > '#qGetApplicationVariables.applicationLocalhostUserImagesPathHTTP#'/> > '#qGetApplicationVariables.applicationLocalhostUserImagesPathAbsolute#'/> > '#qGetApplicationVariables.applicationLocalhostUserDocumentsPathHTTP#'/> > '#qGetApplicationVariables.applicationLocalhostUserDocumentsPathAbsolute#'/> > > > > '#qGetApplicationVariables.applicationDevelopmentDomain#'/> > '#qGetApplicationVariables.applicationDevelopmentUserImagesPathHTTP#'/> > '#qGetApplicationVariables.applicationDevelopmentUserImagesPathAbsolute#'/> > '#qGetApplicationVariables.applicationDevelopmentUserDocumentsPathHTTP#'/> > ='#qGetApplicationVariables.applicationDevelopmentUserDocumentsPathAbsolute# > ' /> > > > > '#qGetApplicationVariables.applicationProductionDomain#'/> > '#qGetApplicationVariables.applicationProductionUserImagesPathHTTP#'/> > '#qGetApplicationVariables.applicationProductionUserImagesPathAbsolute#'/> > '#qGetApplicationVariables.applicationProductionUserDocumentsPathHTTP#'/> > '#qGetApplicationVariables.applicationProductionUserDocumentsPathAbsolute#' > /> > > > > I put all my development sites for clients under the > domain whitestonemedia.com as a subdomain. This lets me > work on whatever level; local, online-development, or production, > that I want just by choosing a different domain name in the browser. > > ie... > > http://localhost/inetpub/webroot/clientSite/index.cfm > http://clientSite.whitestonemedia.com > http://www.clientSite.com > > Any thoughts on this? Seems to be working fine, so far. > > Rick > > > -Original Message- > From: Brian Cain [mailto:bcc9...@gmail.com] > Sent: Thursday, February 17, 2011 12:56 PM > To: cf-talk > Subject: Re: Feedback on this app
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-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: > > > > 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: > > > > select * > fromsiteApplicationSettings > where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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,
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
This will work for a few domains, but if you end up running a few hundred (or thousand) sites off of one codebase this will get to be a maintenance nightmare. 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:10 PM, Jason Fisher wrote: > I usually use CFSWITCH and assign my own app names, which allows me to use > the built-in list nature of CFCASE values: > > > > > > > > > > > > > > > > etc etc ... that way my onApplicationStart is basically mapping 1-to-1 with > my application config table, but I can throw as many domain variations at > it as I want to. > > > > > > From: "Mark A. Kruger" > Sent: Thursday, February 17, 2011 12:59 PM > To: "cf-talk" > Subject: RE: Feedback on this approach to "many sites, one codebase" > (MSOC) > > Ooh... good point Russ. I usually strip off the "www" and replace the > periods with underscores as well. That way I have only 1 app name per > domain. So www.coldfusionmuse.com would be coldfusionmuse_com (don't like > those periods in variable names). > > -Mark > > -----Original Message----- > From: Russ Michaels [mailto:r...@michaels.me.uk] > Sent: Thursday, February 17, 2011 11:45 AM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" > (MSOC) > > For a primae example of how this is best done you can look at many of the > major frameworks which support this type of setup. > MACH-II for example allows you to have a single core install of the > framework which is used by all your apps via a simple mapping. > > If you plan to use the domain name to create the application name and > track > sessions and users and what not, then you also need to allow for the fact > that the site may be accessed via multiple domains (domain.com, > www.domain.com and aliases) or build in automatic redirection so that this > doesn't happen. > > Russ > On Thu, Feb 17, 2011 at 5:28 PM, Rick Faircloth > wrote: > >> 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: >> >> >> >> 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: >> >> datasource="globalSiteManager"> >> select * >> fromsiteApplicationSettings >> where (select strcmp(siteName, '#cgi.server_name#')) = > -1 >> >> >> Then, I set site variables as follows: >> >> > "#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: >> >> > '#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: >> >> > '#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
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I tend to use a siteId, based upon the query return. I can then reuse that ID for things like the folder name of a SiteSpecific media/assets folder. If the site url changes, the siteId does not, eliminating future heartaches. 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 11:28 AM, Rick Faircloth wrote: > 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: > > > > 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: > > > > select * > fromsiteApplicationSettings > where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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:342459 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
> That doesn't really sounds like you're running multiple different > sites off one unified codebase - you're providing a library that is > intended to be reused across multiple, separate applications :) I think that's accurate for this "global site manager." However, I'm trying to determine the best practices for applying the methods I'm using on the site manager to public web sites, themselves. -Original Message- From: Sean Corfield [mailto:seancorfi...@gmail.com] Sent: Friday, February 18, 2011 7:58 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) On Fri, Feb 18, 2011 at 11:36 AM, Rick Faircloth wrote: > When a user visits www.xyz.com, onApplicationStart() runs a > query that retrieves, among other variables, the absolute path > to those images. Realize, the application that I'm referencing > is a "global site manager" (single codebase) for managing > site content on multiple sites (each with a separate codebase, > as these are custom sites). The end user sites are completely > different. I'm using the "global site manager", at this point, > to simply provide a single app to supply CRUD functionality > to the users for their site content. Even the databases for > these sites have little in common. I just decided that instead > of building CRUD functionality over-and-over for each site manager, > I'd build "one site manager to rule them all." :o) That doesn't really sounds like you're running multiple different sites off one unified codebase - you're providing a library that is intended to be reused across multiple, separate applications :) > The userImages path gets set when the application is first run > by onApplicationStart() and a query, qGetApplicationVariables, is run > that retrieves info such as the userImages path, or, in this case, > qGetApplicationVariables.userImagesPathAbsolute. Then, the query > value for the userImages path is cfset to application.userImagesPathAbsolute > for use throughout the site. I have a site object containing all the site-specific settings. When a request comes in, the domain in the URL is mapped to a site object, and that is used throughout the request for any site-specific info. Site objects are cached for efficiency, of course. This allows me to clearly separate code / data that is common across all sites from that which varies. > If I have the same application name, wouldn't the userImages path > variable be overwritten when another user visits another site using > the same site manager codebase and onApplicationStart() is run again? onApplicationStart() is run once for the entire system in my model. I don't use bare application variables anywhere (because I use a framework that has all the services injected as needed, or uses a bean factory accessible within the framework). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwo ~| 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:342449 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
On Fri, Feb 18, 2011 at 11:36 AM, Rick Faircloth wrote: > When a user visits www.xyz.com, onApplicationStart() runs a > query that retrieves, among other variables, the absolute path > to those images. Realize, the application that I'm referencing > is a "global site manager" (single codebase) for managing > site content on multiple sites (each with a separate codebase, > as these are custom sites). The end user sites are completely > different. I'm using the "global site manager", at this point, > to simply provide a single app to supply CRUD functionality > to the users for their site content. Even the databases for > these sites have little in common. I just decided that instead > of building CRUD functionality over-and-over for each site manager, > I'd build "one site manager to rule them all." :o) That doesn't really sounds like you're running multiple different sites off one unified codebase - you're providing a library that is intended to be reused across multiple, separate applications :) > The userImages path gets set when the application is first run > by onApplicationStart() and a query, qGetApplicationVariables, is run > that retrieves info such as the userImages path, or, in this case, > qGetApplicationVariables.userImagesPathAbsolute. Then, the query > value for the userImages path is cfset to application.userImagesPathAbsolute > for use throughout the site. I have a site object containing all the site-specific settings. When a request comes in, the domain in the URL is mapped to a site object, and that is used throughout the request for any site-specific info. Site objects are cached for efficiency, of course. This allows me to clearly separate code / data that is common across all sites from that which varies. > If I have the same application name, wouldn't the userImages path > variable be overwritten when another user visits another site using > the same site manager codebase and onApplicationStart() is run again? onApplicationStart() is run once for the entire system in my model. I don't use bare application variables anywhere (because I use a framework that has all the services injected as needed, or uses a bean factory accessible within the framework). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwo ~| 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:342447 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Good points about the single application name. However, it brings into question my entire approach to application variables. Take, for instance, my path to userImages. When a user visits www.xyz.com, onApplicationStart() runs a query that retrieves, among other variables, the absolute path to those images. Realize, the application that I'm referencing is a "global site manager" (single codebase) for managing site content on multiple sites (each with a separate codebase, as these are custom sites). The end user sites are completely different. I'm using the "global site manager", at this point, to simply provide a single app to supply CRUD functionality to the users for their site content. Even the databases for these sites have little in common. I just decided that instead of building CRUD functionality over-and-over for each site manager, I'd build "one site manager to rule them all." :o) Now, for one site, the userImages path is, say, e:\inetpub\webroot\siteOne\userImages and for another site, the userImages path is e:\inetpub\webroot\siteTwo\userImages The userImages path gets set when the application is first run by onApplicationStart() and a query, qGetApplicationVariables, is run that retrieves info such as the userImages path, or, in this case, qGetApplicationVariables.userImagesPathAbsolute. Then, the query value for the userImages path is cfset to application.userImagesPathAbsolute for use throughout the site. If I have the same application name, wouldn't the userImages path variable be overwritten when another user visits another site using the same site manager codebase and onApplicationStart() is run again? Rick -Original Message- From: Sean Corfield [mailto:seancorfi...@gmail.com] Sent: Friday, February 18, 2011 1:24 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) On Fri, Feb 18, 2011 at 6:14 AM, Eric Cobb wrote: > One thing you may want to take into consideration, if you plan on having > many sites run through this codebase, is NOT giving each site a unique > application name. I always take the approach of a single application name - for the reasons Eric presents - and I also typically have one DSN and all sites are in a single multi-tenant schema (and I'll be explaining all this in my Multi-Tenant Architecture talk at cf.Objective() BTW). Re: ?reinit=1 situations - what do you normally need to do that for? Refreshing the cache for a particular site? Design that into your admin system. Refreshing code after pushing a new file? As Eric points out, you need to reinit *every* application in that situation so you'd end up restarting the entire server. With MSOC, you need to consider your DB schema as part of your code too - that "OC" part means "One Schema" too. "OC" really means "One Application" otherwise you're going to be running multiple identical copies of your code and wasting memory. Steve asked "wouldn't it make sense to push it into the server scope?" - that can interfere with running any other applications on the server - and you probably want an admin application running alongside your multiple user applications. Now, you may share code between the admin and the user applications but it will be lower level components, if any, and you typically only have one admin application so you're at most running two copies of your code. You've also got startup issues to think about - if you have multiple applications and need to initialize server scope, there's no safe hook to do that (until we got CF9's onServerStart() / Server.cfc). Some things to think about... If you're at cf.Objective() and want to hear more on this topic, attend my talk and catch me in the bar afterward! If you're not yet registered for cf.Objective()... It'll be a great conference: five tracks this year, lots of awesome topics from great speakers, all packed into three days in a relatively central location (Minneapolis). You've missed the early bird now but it's still great value at under $1k! In addition to my Multi-Tenant Architecture talk, I'm giving an Introduction to Functional Programming session which addresses things like careful management of shared data and why side-effect-free code is easier to test and easier to get right in the first place (amongst many other functional techniques, some of which you can apply directly to CFML and some of which will at least make you think differently about solving problems). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| Order the Adobe Coldfusion Antholog
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
On Fri, Feb 18, 2011 at 6:14 AM, Eric Cobb wrote: > One thing you may want to take into consideration, if you plan on having > many sites run through this codebase, is NOT giving each site a unique > application name. I always take the approach of a single application name - for the reasons Eric presents - and I also typically have one DSN and all sites are in a single multi-tenant schema (and I'll be explaining all this in my Multi-Tenant Architecture talk at cf.Objective() BTW). Re: ?reinit=1 situations - what do you normally need to do that for? Refreshing the cache for a particular site? Design that into your admin system. Refreshing code after pushing a new file? As Eric points out, you need to reinit *every* application in that situation so you'd end up restarting the entire server. With MSOC, you need to consider your DB schema as part of your code too - that "OC" part means "One Schema" too. "OC" really means "One Application" otherwise you're going to be running multiple identical copies of your code and wasting memory. Steve asked "wouldn't it make sense to push it into the server scope?" - that can interfere with running any other applications on the server - and you probably want an admin application running alongside your multiple user applications. Now, you may share code between the admin and the user applications but it will be lower level components, if any, and you typically only have one admin application so you're at most running two copies of your code. You've also got startup issues to think about - if you have multiple applications and need to initialize server scope, there's no safe hook to do that (until we got CF9's onServerStart() / Server.cfc). Some things to think about... If you're at cf.Objective() and want to hear more on this topic, attend my talk and catch me in the bar afterward! If you're not yet registered for cf.Objective()... It'll be a great conference: five tracks this year, lots of awesome topics from great speakers, all packed into three days in a relatively central location (Minneapolis). You've missed the early bird now but it's still great value at under $1k! In addition to my Multi-Tenant Architecture talk, I'm giving an Introduction to Functional Programming session which addresses things like careful management of shared data and why side-effect-free code is easier to test and easier to get right in the first place (amongst many other functional techniques, some of which you can apply directly to CFML and some of which will at least make you think differently about solving problems). -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ~| 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:342436 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
I've never used the server scope in apps, so it's not a question I can answer...perhaps others will chime in on this one. And, as part of this situation, there are almost no variables that are shared between applications, so I don't see that there would be many variables to put into the server scope. Every site has its own database, paths, etc. Rick -Original Message- From: DURETTE, STEVEN J (ATTASIAIT) [mailto:sd1...@att.com] Sent: Friday, February 18, 2011 10:11 AM To: cf-talk Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) Probably a stupid question, but if the data was used across applications wouldn't it make sense to push it into the server scope? That would allow you to have one copy of the needed items, but still let you keep the applications separate. I know that a lot of the time having a different application name for each application while troubleshooting can be extremely helpful. I don't have a situation like this and I hardly ever look at the server scope, so I'm just asking because it will help further my knowledge. :) Steve -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Friday, February 18, 2011 9:15 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) One thing you may want to take into consideration, if you plan on having many sites run through this codebase, is NOT giving each site a unique application name. (as in ). I once worked on a MSOC system that ran somewhere around 2700 websites, and each site had its own application name. So, every time we cached a CFC in the application scope, we had 2700 separate instances of it, even though they were all identical. We had 2700 "application.dsn" variables stored in memory, even though they were all identical. We had multiple CF servers each trying to store and manage the same 2700 separate applications, all of which were completely identical. And the worst part was, there was no passing "?reinit=1" if we made code changes and needed to reset the application scope, we had to restart each CF server and take all 2700 sites offline in order to reset all of the applications. To me, this always seemed inefficient, and a gross waste of CF processes and memory. Just some thoughts I wanted to throw out there. Definitely something to think about if you're planning on having a large number of sites on your system. Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com ~| 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:342429 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Thanks for the feedback, Eric. Wouldn't sharing an application name cause some sharing of variables between sites? And: So using ?reinit=1 or something similar resets variables within *every* application, even with different application names? I thought the main reason for using different application names was to prevent application, session, etc variable bleed-over and to allow reinitializing of one application without affecting others, even on the same codebase. ??? -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Friday, February 18, 2011 9:15 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) One thing you may want to take into consideration, if you plan on having many sites run through this codebase, is NOT giving each site a unique application name. (as in ). I once worked on a MSOC system that ran somewhere around 2700 websites, and each site had its own application name. So, every time we cached a CFC in the application scope, we had 2700 separate instances of it, even though they were all identical. We had 2700 "application.dsn" variables stored in memory, even though they were all identical. We had multiple CF servers each trying to store and manage the same 2700 separate applications, all of which were completely identical. And the worst part was, there was no passing "?reinit=1" if we made code changes and needed to reset the application scope, we had to restart each CF server and take all 2700 sites offline in order to reset all of the applications. To me, this always seemed inefficient, and a gross waste of CF processes and memory. Just some thoughts I wanted to throw out there. Definitely something to think about if you're planning on having a large number of sites on your system. Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 2/17/2011 8:59 PM, Rick Faircloth wrote: > Your approach at Broadchoice sounds exactly like what I'm > anticipating implementing... > > > -Original Message- > From: Sean Corfield [mailto:seancorfi...@gmail.com] > Sent: Thursday, February 17, 2011 5:58 PM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > On Thu, Feb 17, 2011 at 10:21 AM, Robert Harrison > wrote: >> 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. > > It really depends on how you set up the contract and the expectations. > Broadchoice (where I worked in 2008) has a software-as-a-service CMS > which hosts a number of high-profile client sites. It's very clear to > the clients that they're using a multi-tenant SaaS platform and > therefore they know upfront that this isn't a site they can just "take > over" (although there is an option to license the codebase for an > internal installation). > >> 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. > > At Broadchoice we tackled this by designing a pluggable, modular > architecture for "applications" that could literally be dropped into > the (single) codebase and then configured to be available on any > client sites. The nice thing about this is that one client may pay for > the module to be developed but it's still provided to them as a > service - they're not purchasing the code - and then it can be offered > to other clients, as a paid option if appropriate. > > The key is really in deciding whether you're "just" hosting a number > of sites or whether you're offering a "website platform" in a SaaS > model. > > You might also want to read Steve "Cutter" Blades blog series about MSOC: > > http://blog.cutterscrossing.com/index.cfm/MSOC > > At World Singles, we have about 50 sites all running on a single > codebase. Mostly the sites differ in branding and look'n'feel but > there are functional differences between many of the sites, managed > with a similar model to what we used at Broadchoice. > > > ~| 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:342428 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Probably a stupid question, but if the data was used across applications wouldn't it make sense to push it into the server scope? That would allow you to have one copy of the needed items, but still let you keep the applications separate. I know that a lot of the time having a different application name for each application while troubleshooting can be extremely helpful. I don't have a situation like this and I hardly ever look at the server scope, so I'm just asking because it will help further my knowledge. :) Steve -Original Message- From: Eric Cobb [mailto:cft...@ecartech.com] Sent: Friday, February 18, 2011 9:15 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) One thing you may want to take into consideration, if you plan on having many sites run through this codebase, is NOT giving each site a unique application name. (as in ). I once worked on a MSOC system that ran somewhere around 2700 websites, and each site had its own application name. So, every time we cached a CFC in the application scope, we had 2700 separate instances of it, even though they were all identical. We had 2700 "application.dsn" variables stored in memory, even though they were all identical. We had multiple CF servers each trying to store and manage the same 2700 separate applications, all of which were completely identical. And the worst part was, there was no passing "?reinit=1" if we made code changes and needed to reset the application scope, we had to restart each CF server and take all 2700 sites offline in order to reset all of the applications. To me, this always seemed inefficient, and a gross waste of CF processes and memory. Just some thoughts I wanted to throw out there. Definitely something to think about if you're planning on having a large number of sites on your system. Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com ~| 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:342426 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
One thing you may want to take into consideration, if you plan on having many sites run through this codebase, is NOT giving each site a unique application name. (as in ). I once worked on a MSOC system that ran somewhere around 2700 websites, and each site had its own application name. So, every time we cached a CFC in the application scope, we had 2700 separate instances of it, even though they were all identical. We had 2700 "application.dsn" variables stored in memory, even though they were all identical. We had multiple CF servers each trying to store and manage the same 2700 separate applications, all of which were completely identical. And the worst part was, there was no passing "?reinit=1" if we made code changes and needed to reset the application scope, we had to restart each CF server and take all 2700 sites offline in order to reset all of the applications. To me, this always seemed inefficient, and a gross waste of CF processes and memory. Just some thoughts I wanted to throw out there. Definitely something to think about if you're planning on having a large number of sites on your system. Thanks, Eric Cobb ECAR Technologies, LLC http://www.ecartech.com http://www.cfgears.com On 2/17/2011 8:59 PM, Rick Faircloth wrote: > Your approach at Broadchoice sounds exactly like what I'm > anticipating implementing... > > > -Original Message- > From: Sean Corfield [mailto:seancorfi...@gmail.com] > Sent: Thursday, February 17, 2011 5:58 PM > To: cf-talk > Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) > > > On Thu, Feb 17, 2011 at 10:21 AM, Robert Harrison > wrote: >> 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. > > It really depends on how you set up the contract and the expectations. > Broadchoice (where I worked in 2008) has a software-as-a-service CMS > which hosts a number of high-profile client sites. It's very clear to > the clients that they're using a multi-tenant SaaS platform and > therefore they know upfront that this isn't a site they can just "take > over" (although there is an option to license the codebase for an > internal installation). > >> 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. > > At Broadchoice we tackled this by designing a pluggable, modular > architecture for "applications" that could literally be dropped into > the (single) codebase and then configured to be available on any > client sites. The nice thing about this is that one client may pay for > the module to be developed but it's still provided to them as a > service - they're not purchasing the code - and then it can be offered > to other clients, as a paid option if appropriate. > > The key is really in deciding whether you're "just" hosting a number > of sites or whether you're offering a "website platform" in a SaaS > model. > > You might also want to read Steve "Cutter" Blades blog series about MSOC: > > http://blog.cutterscrossing.com/index.cfm/MSOC > > At World Singles, we have about 50 sites all running on a single > codebase. Mostly the sites differ in branding and look'n'feel but > there are functional differences between many of the sites, managed > with a similar model to what we used at Broadchoice. > > > ~| 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:342425 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Your approach at Broadchoice sounds exactly like what I'm anticipating implementing... -Original Message- From: Sean Corfield [mailto:seancorfi...@gmail.com] Sent: Thursday, February 17, 2011 5:58 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) On Thu, Feb 17, 2011 at 10:21 AM, Robert Harrison wrote: > 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. It really depends on how you set up the contract and the expectations. Broadchoice (where I worked in 2008) has a software-as-a-service CMS which hosts a number of high-profile client sites. It's very clear to the clients that they're using a multi-tenant SaaS platform and therefore they know upfront that this isn't a site they can just "take over" (although there is an option to license the codebase for an internal installation). > 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. At Broadchoice we tackled this by designing a pluggable, modular architecture for "applications" that could literally be dropped into the (single) codebase and then configured to be available on any client sites. The nice thing about this is that one client may pay for the module to be developed but it's still provided to them as a service - they're not purchasing the code - and then it can be offered to other clients, as a paid option if appropriate. The key is really in deciding whether you're "just" hosting a number of sites or whether you're offering a "website platform" in a SaaS model. You might also want to read Steve "Cutter" Blades blog series about MSOC: http://blog.cutterscrossing.com/index.cfm/MSOC At World Singles, we have about 50 sites all running on a single codebase. Mostly the sites differ in branding and look'n'feel but there are functional differences between many of the sites, managed with a similar model to what we used at Broadchoice. ~| 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:342416 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Yes, that's what I've done. The application.cfc simply runs a query based on the domain name and returns all the variable values, that are then set once as application variables. The application.cfc doesn't contain any hard-coded values. There's no need to clutter up the application.cfc with all the domain values. Getting them from the database is more efficient. I just have to tweak the database and add values as the app grows. -Original Message- From: Jason Fisher [mailto:ja...@wanax.com] Sent: Thursday, February 17, 2011 3:04 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) +1 to databasing all of it ... if you've got a system where these things change a lot, particularly new domains that might impact the Application.cfc, then definitely push the config to the database. As was mentioned before, you can handle redirects there as well: if domain.com is found in the DB and if the database record for that domain has a redirect to www.domain.com, then handle the redirect. Allows you to abstract it all in Application.cfc while giving you great flexibility in the administration of it. From: "Steve Bryant" Sent: Thursday, February 17, 2011 2:45 PM To: "cf-talk" Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) I prefer to have the domain names in a database mapped to a primary domain name or an application name. This allows me to have a UI to enter new domain names as they are needed (we add them pretty frequently). That also allows you to write code to your web server to add bindings for each domain name to your web site. If your DNS server allows, then you can also automatically put in the DNS entry there. If you have a large MSOC system that frequently adds domain names then a little automation can go a long way. Steve >I usually use CFSWITCH and assign my own app names, which allows me to use >the built-in list nature of CFCASE values: > > > > > > > > > > > > > > > >etc etc ... that way my onApplicationStart is basically mapping 1-to-1 with >my application config table, but I can throw as many domain variations at >it as I want to. ~| 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:342415 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Just for reference, I'm using a VPS, which is great. Complete control and no limitations on what I can do or install. Based on all this discussion, I can really see the need for a tutorial on this approach...from server setup to codebase to styles. -Original Message- From: Jason Fisher [mailto:ja...@wanax.com] Sent: Thursday, February 17, 2011 1:45 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) If you're using shared server space, though, no need to spend money on a bunch of separate sites if they all need to use the same codebase. Just point them all the same IP, which I would do even if they're all on separate sites but the same server, but then I get to really have all the code in one place, with only having separate directories for site assets (CSS, HTML templates, images, file resources), just like Mura or other CMS systems do. I don't think SEO would have any way of knowing whether or not the site was set up separately in IIS or it was one app serving content on each domain through a single site in IIS. As for webstats, I go with Google Analytics, which is JS-based tracking, so the logs of the site itself are irrelevant because I don't find the need to do deep web server diagnostics. From: "Russ Michaels" Sent: Thursday, February 17, 2011 1:21 PM To: "cf-talk" Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) FYI it is actually a best practice these days to only have 1 domain accessing your site and to redirect all others to that domain (including www) whether doing it in your code or using url redirection. You saw one of the reasons which is managing your code base, other reasons include web stats traffic (which usually only tracks the primary domain), SEO (which supposedly doesn't like multiple domains pointing to same site). -- Russ Michaels www.bluethunderinternet.com : Business hosting services & solutions www.cfmldeveloper.com: ColdFusion developer community www.michaels.me.uk : my blog www.cfsearch.com : ColdFusion search engine ** *skype me* : russmichaels ~| 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:342414 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
So, you think a better approach is to simply copy the codebase and customize as needed? For the site manager app I've been building this isn't an issue, but for front-end sites, I can see where customization would be a problem. I've started constructing my sites into "modules", where all files, including HTML, CF, jQuery, and CSS are included in each module for ease of development. It makes for many more files, but constantly trying to work between the HTML, CF, jQuery, and CSS, if those files are centralized, just became too complex to be worth it. Not a very optimized approach, but helped maintain my sanity. My plan is to be able to create customizations in separate modules and then, after a module is created once, from that point on offer it as an option for a site. One site's customization becomes a codebase option. The ole "add a calendar", "add announcements", etc., to your site. Maybe this will work. -Original Message- From: Mike Kear [mailto:afpwebwo...@gmail.com] Sent: Thursday, February 17, 2011 1:36 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) I would agree with Robert.I was contracted to work on a site once that was doing just what you want - they were an application provider for their clients web sites. All the clients provided was a look and feel template, and they did the rest. At first it was easy. In fact they had one core file that did all the grunt work for the application, then a client wanted something a bit different. It was needed in a hurry, and wasnt much of a change, so they just put in a and made the change in that core file.Then another change was needed. And another. And one more complex for another client. Before long the core file was strewn with all these http://afpwebworks.com ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month On Fri, Feb 18, 2011 at 5:21 AM, 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.c ~| 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:342413 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
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:rob...@austin-williams.com] 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: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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: 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
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
I guess with the approach you describe below, that I'd use cgi.http_referer instead of cgi.server_name to set variables, right? -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: Thursday, February 17, 2011 1:21 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) FYI it is actually a best practice these days to only have 1 domain accessing your site and to redirect all others to that domain (including www) whether doing it in your code or using url redirection. You saw one of the reasons which is managing your code base, other reasons include web stats traffic (which usually only tracks the primary domain), SEO (which supposedly doesn't like multiple domains pointing to same site). -- Russ Michaels www.bluethunderinternet.com : Business hosting services & solutions www.cfmldeveloper.com: ColdFusion developer community www.michaels.me.uk : my blog www.cfsearch.com : ColdFusion search engine ** *skype me* : russmichaels ~| 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:342411 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
On Thu, Feb 17, 2011 at 10:21 AM, Robert Harrison wrote: > 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. It really depends on how you set up the contract and the expectations. Broadchoice (where I worked in 2008) has a software-as-a-service CMS which hosts a number of high-profile client sites. It's very clear to the clients that they're using a multi-tenant SaaS platform and therefore they know upfront that this isn't a site they can just "take over" (although there is an option to license the codebase for an internal installation). > 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. At Broadchoice we tackled this by designing a pluggable, modular architecture for "applications" that could literally be dropped into the (single) codebase and then configured to be available on any client sites. The nice thing about this is that one client may pay for the module to be developed but it's still provided to them as a service - they're not purchasing the code - and then it can be offered to other clients, as a paid option if appropriate. The key is really in deciding whether you're "just" hosting a number of sites or whether you're offering a "website platform" in a SaaS model. You might also want to read Steve "Cutter" Blades blog series about MSOC: http://blog.cutterscrossing.com/index.cfm/MSOC At World Singles, we have about 50 sites all running on a single codebase. Mostly the sites differ in branding and look'n'feel but there are functional differences between many of the sites, managed with a similar model to what we used at Broadchoice. -- Sean A Corfield -- (904) 302-SEAN Railo Technologies, Inc. -- http://getrailo.com/ An Architect's View -- http://corfield.org/ "If you're not annoying somebody, you're not really alive." -- Margaret At ~| 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:342410 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
+1 to databasing all of it ... if you've got a system where these things change a lot, particularly new domains that might impact the Application.cfc, then definitely push the config to the database. As was mentioned before, you can handle redirects there as well: if domain.com is found in the DB and if the database record for that domain has a redirect to www.domain.com, then handle the redirect. Allows you to abstract it all in Application.cfc while giving you great flexibility in the administration of it. From: "Steve Bryant" Sent: Thursday, February 17, 2011 2:45 PM To: "cf-talk" Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) I prefer to have the domain names in a database mapped to a primary domain name or an application name. This allows me to have a UI to enter new domain names as they are needed (we add them pretty frequently). That also allows you to write code to your web server to add bindings for each domain name to your web site. If your DNS server allows, then you can also automatically put in the DNS entry there. If you have a large MSOC system that frequently adds domain names then a little automation can go a long way. Steve >I usually use CFSWITCH and assign my own app names, which allows me to use >the built-in list nature of CFCASE values: > > > > > > > > > > > > > > > >etc etc ... that way my onApplicationStart is basically mapping 1-to-1 with >my application config table, but I can throw as many domain variations at >it as I want to. ~| 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:342406 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I prefer to have the domain names in a database mapped to a primary domain name or an application name. This allows me to have a UI to enter new domain names as they are needed (we add them pretty frequently). That also allows you to write code to your web server to add bindings for each domain name to your web site. If your DNS server allows, then you can also automatically put in the DNS entry there. If you have a large MSOC system that frequently adds domain names then a little automation can go a long way. Steve >I usually use CFSWITCH and assign my own app names, which allows me to use >the built-in list nature of CFCASE values: > > > > > > > > > > > > > > > >etc etc ... that way my onApplicationStart is basically mapping 1-to-1 with >my application config table, but I can throw as many domain variations at >it as I want to. ~| 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:342405 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
If you're using shared server space, though, no need to spend money on a bunch of separate sites if they all need to use the same codebase. Just point them all the same IP, which I would do even if they're all on separate sites but the same server, but then I get to really have all the code in one place, with only having separate directories for site assets (CSS, HTML templates, images, file resources), just like Mura or other CMS systems do. I don't think SEO would have any way of knowing whether or not the site was set up separately in IIS or it was one app serving content on each domain through a single site in IIS. As for webstats, I go with Google Analytics, which is JS-based tracking, so the logs of the site itself are irrelevant because I don't find the need to do deep web server diagnostics. From: "Russ Michaels" Sent: Thursday, February 17, 2011 1:21 PM To: "cf-talk" Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) FYI it is actually a best practice these days to only have 1 domain accessing your site and to redirect all others to that domain (including www) whether doing it in your code or using url redirection. You saw one of the reasons which is managing your code base, other reasons include web stats traffic (which usually only tracks the primary domain), SEO (which supposedly doesn't like multiple domains pointing to same site). -- Russ Michaels www.bluethunderinternet.com : Business hosting services & solutions www.cfmldeveloper.com: ColdFusion developer community www.michaels.me.uk : my blog www.cfsearch.com : ColdFusion search engine ** *skype me* : russmichaels ~| 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:342404 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I would agree with Robert.I was contracted to work on a site once that was doing just what you want - they were an application provider for their clients web sites. All the clients provided was a look and feel template, and they did the rest. At first it was easy. In fact they had one core file that did all the grunt work for the application, then a client wanted something a bit different. It was needed in a hurry, and wasnt much of a change, so they just put in a and made the change in that core file.Then another change was needed. And another. And one more complex for another client. Before long the core file was strewn with all these http://afpwebworks.com ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month On Fri, Feb 18, 2011 at 5:21 AM, 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.c ~| 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:342403 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
To avoid any inaccuracy about referencing the cgi.server_name, I opted to use "contains" in the CF: Seems like that would eliminate any problems with top-level domains, but wouldn't address subdomain issues... -Original Message- From: Mark A. Kruger [mailto:mkru...@cfwebtools.com] Sent: Thursday, February 17, 2011 12:55 PM To: cf-talk Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) Ooh... good point Russ. I usually strip off the "www" and replace the periods with underscores as well. That way I have only 1 app name per domain. So www.coldfusionmuse.com would be coldfusionmuse_com (don't like those periods in variable names). -Mark -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: Thursday, February 17, 2011 11:45 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) For a primae example of how this is best done you can look at many of the major frameworks which support this type of setup. MACH-II for example allows you to have a single core install of the framework which is used by all your apps via a simple mapping. If you plan to use the domain name to create the application name and track sessions and users and what not, then you also need to allow for the fact that the site may be accessed via multiple domains (domain.com, www.domain.com and aliases) or build in automatic redirection so that this doesn't happen. Russ On Thu, Feb 17, 2011 at 5:28 PM, Rick Faircloth wrote: > > 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: > > > > 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: > > > >select * >fromsiteApplicationSettings >where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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:342402 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Thanks, Brian... good info on the subdomains. Re: virtual directories... I was about to say "yes", but after looking at the directories of the sites involving the "global site manager", I realized I didn't have any virtual IIS directories in users' sites. (I have them for other purposes unrelated to this "global site manager"...) I've been setting full http and absolute paths for image and document handling, etc. using variables and values from the database. One reason for this is my setup for my development cycle from the local site, to an online development site, to the full production site. I've been using this code for establishing which type of site the "global site manager" should be working with: I put all my development sites for clients under the domain whitestonemedia.com as a subdomain. This lets me work on whatever level; local, online-development, or production, that I want just by choosing a different domain name in the browser. ie... http://localhost/inetpub/webroot/clientSite/index.cfm http://clientSite.whitestonemedia.com http://www.clientSite.com Any thoughts on this? Seems to be working fine, so far. Rick -Original Message- From: Brian Cain [mailto:bcc9...@gmail.com] Sent: Thursday, February 17, 2011 12:56 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) I have built two applications under this method, and you are using many of the same ideas. Mine have been up and running for years with no major issues. In regard to the domain name issue mentioned by Russ, a simple workaround for this is to use a bit of string parsing. You can parse out the domain, and drop the sub domain into a separate variable to be used for additional processing or styling. For example, take the following theoretical URLs mydomain.com, www.mydomain.com, and blogs.mydomain.com. Using string parsing you can always be assured the mydomain.com will always be your primary reference point to setup DSN and any other site specific variables that need to be set. You can then drop the sub domain "blogs" into another variable that would allow you to modify settings for the primary domain such as template or navigation links. BTW, I am using IIS with virtual directories to include my code base. What setup are you using? Good luck, Brian Cain ~| 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:342401 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
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: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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342400 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
FYI it is actually a best practice these days to only have 1 domain accessing your site and to redirect all others to that domain (including www) whether doing it in your code or using url redirection. You saw one of the reasons which is managing your code base, other reasons include web stats traffic (which usually only tracks the primary domain), SEO (which supposedly doesn't like multiple domains pointing to same site). -- Russ Michaels www.bluethunderinternet.com : Business hosting services & solutions www.cfmldeveloper.com: ColdFusion developer community www.michaels.me.uk : my blog www.cfsearch.com : ColdFusion search engine ** *skype me* : russmichaels ~| 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:342399 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Thanks, Jason! :o) -Original Message- From: Jason Fisher [mailto:ja...@wanax.com] Sent: Thursday, February 17, 2011 12:55 PM To: cf-talk Subject: re: Feedback on this approach to "many sites, one codebase" (MSOC) Yeah, that works just fine, Rick. Have used variations of that approach for quite a few years, both with and without a 'framework' in place, and in any case that code sits quite well in the Application.cfc as you've outlined. From: "Rick Faircloth" Sent: Thursday, February 17, 2011 12:29 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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342398 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Thanks, Russ! Good info concerning the "access via multiple domains" and redirecting. That's something I hadn't considered. -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: Thursday, February 17, 2011 12:45 PM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) For a primae example of how this is best done you can look at many of the major frameworks which support this type of setup. MACH-II for example allows you to have a single core install of the framework which is used by all your apps via a simple mapping. If you plan to use the domain name to create the application name and track sessions and users and what not, then you also need to allow for the fact that the site may be accessed via multiple domains (domain.com, www.domain.com and aliases) or build in automatic redirection so that this doesn't happen. Russ On Thu, Feb 17, 2011 at 5:28 PM, Rick Faircloth wrote: > > 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: > > > > 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: > > > >select * >fromsiteApplicationSettings >where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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:342397 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Thanks, Mark! Good to know! :o) -Original Message- From: Mark A. Kruger [mailto:mkru...@cfwebtools.com] Sent: Thursday, February 17, 2011 12:39 PM To: cf-talk Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) Rick, Having managed many many such sites I can tell you that your choices and approach are pretty standard. I think you are on track (though careful testing is of course warranted). -mark Mark A. Kruger, MCSE, CFG (402) 408-3733 ext 105 Skype: markakruger www.cfwebtools.com www.coldfusionmuse.com www.necfug.com -Original Message- From: Rick Faircloth [mailto:r...@whitestonemedia.com] Sent: Thursday, February 17, 2011 11:28 AM 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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342396 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
I usually use CFSWITCH and assign my own app names, which allows me to use the built-in list nature of CFCASE values: etc etc ... that way my onApplicationStart is basically mapping 1-to-1 with my application config table, but I can throw as many domain variations at it as I want to. From: "Mark A. Kruger" Sent: Thursday, February 17, 2011 12:59 PM To: "cf-talk" Subject: RE: Feedback on this approach to "many sites, one codebase" (MSOC) Ooh... good point Russ. I usually strip off the "www" and replace the periods with underscores as well. That way I have only 1 app name per domain. So www.coldfusionmuse.com would be coldfusionmuse_com (don't like those periods in variable names). -Mark -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: Thursday, February 17, 2011 11:45 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) For a primae example of how this is best done you can look at many of the major frameworks which support this type of setup. MACH-II for example allows you to have a single core install of the framework which is used by all your apps via a simple mapping. If you plan to use the domain name to create the application name and track sessions and users and what not, then you also need to allow for the fact that the site may be accessed via multiple domains (domain.com, www.domain.com and aliases) or build in automatic redirection so that this doesn't happen. Russ On Thu, Feb 17, 2011 at 5:28 PM, Rick Faircloth wrote: > > 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: > > > > 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: > > > >select * >fromsiteApplicationSettings >where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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:342395 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Ooh... good point Russ. I usually strip off the "www" and replace the periods with underscores as well. That way I have only 1 app name per domain. So www.coldfusionmuse.com would be coldfusionmuse_com (don't like those periods in variable names). -Mark -Original Message- From: Russ Michaels [mailto:r...@michaels.me.uk] Sent: Thursday, February 17, 2011 11:45 AM To: cf-talk Subject: Re: Feedback on this approach to "many sites, one codebase" (MSOC) For a primae example of how this is best done you can look at many of the major frameworks which support this type of setup. MACH-II for example allows you to have a single core install of the framework which is used by all your apps via a simple mapping. If you plan to use the domain name to create the application name and track sessions and users and what not, then you also need to allow for the fact that the site may be accessed via multiple domains (domain.com, www.domain.com and aliases) or build in automatic redirection so that this doesn't happen. Russ On Thu, Feb 17, 2011 at 5:28 PM, Rick Faircloth wrote: > > 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: > > > > 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: > > > >select * >fromsiteApplicationSettings >where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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:342394 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
I have built two applications under this method, and you are using many of the same ideas. Mine have been up and running for years with no major issues. In regard to the domain name issue mentioned by Russ, a simple workaround for this is to use a bit of string parsing. You can parse out the domain, and drop the sub domain into a separate variable to be used for additional processing or styling. For example, take the following theoretical URLs mydomain.com, www.mydomain.com, and blogs.mydomain.com. Using string parsing you can always be assured the mydomain.com will always be your primary reference point to setup DSN and any other site specific variables that need to be set. You can then drop the sub domain "blogs" into another variable that would allow you to modify settings for the primary domain such as template or navigation links. BTW, I am using IIS with virtual directories to include my code base. What setup are you using? Good luck, Brian Cain ~| 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:342393 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
re: Feedback on this approach to "many sites, one codebase" (MSOC)
Yeah, that works just fine, Rick. Have used variations of that approach for quite a few years, both with and without a 'framework' in place, and in any case that code sits quite well in the Application.cfc as you've outlined. From: "Rick Faircloth" Sent: Thursday, February 17, 2011 12:29 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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342392 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
Re: Feedback on this approach to "many sites, one codebase" (MSOC)
For a primae example of how this is best done you can look at many of the major frameworks which support this type of setup. MACH-II for example allows you to have a single core install of the framework which is used by all your apps via a simple mapping. If you plan to use the domain name to create the application name and track sessions and users and what not, then you also need to allow for the fact that the site may be accessed via multiple domains (domain.com, www.domain.com and aliases) or build in automatic redirection so that this doesn't happen. Russ On Thu, Feb 17, 2011 at 5:28 PM, Rick Faircloth wrote: > > 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: > > > > 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: > > > >select * >fromsiteApplicationSettings >where (select strcmp(siteName, '#cgi.server_name#')) = -1 > > > > Then, I set site variables as follows: > > "#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: > > '#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: > > '#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:342391 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
RE: Feedback on this approach to "many sites, one codebase" (MSOC)
Rick, Having managed many many such sites I can tell you that your choices and approach are pretty standard. I think you are on track (though careful testing is of course warranted). -mark Mark A. Kruger, MCSE, CFG (402) 408-3733 ext 105 Skype: markakruger www.cfwebtools.com www.coldfusionmuse.com www.necfug.com -Original Message- From: Rick Faircloth [mailto:r...@whitestonemedia.com] Sent: Thursday, February 17, 2011 11:28 AM 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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342390 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
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: 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: select * fromsiteApplicationSettings where (select strcmp(siteName, '#cgi.server_name#')) = -1 Then, I set site variables as follows: http://www.amazon.com/Adobe-Coldfusion-Anthology/dp/1430272155/?tag=houseoffusion Archive: http://www.houseoffusion.com/groups/cf-talk/message.cfm/messageid:342389 Subscription: http://www.houseoffusion.com/groups/cf-talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/groups/cf-talk/unsubscribe.cfm
