That’s exactly what we do
Brad has said the same thing and I think this design curiosity fits well with what he has outlines. Andrew, this blog entry was helpful but it is predicated on the individual sites existing in the same webroot…in my example, that will not be the case. Basically (with help from an application template), a new site “extends” another so that the “other” site serves as the core of the code and anything in the newly created site can override.
www.site1.com document root = /htdocs/site1
www.site2.com document root = /htdocs/site2
<no url, no public interface directely> document roomt = /htdocs/shared
so if I go to www.site1.com/index.cfm/home/index and it DOES NOT exist, the handler from within /htdocs/shared.
if I go to www.site2.com/index.cfm/home/index and it DOES exist, that’s the handler that is used RATHER than the shared one.
Brad…is that in line with what you do?
ok…so what is the “big” secret I’m missing then. If site1 and site2 are treated by apache or IIS as document roots…oh wait a second…you are creating a CF mapping to /shared and then creating a virtual directory (symlink) to /shared in site1 and site 2?
Nope no CF mapping…
I don’t work with Apache so I will describe this the best as I can.
When we create a website in IIS, we point it to the core application, any new website is then created and pointed to the core application. Now the thing here is unless you make some subtle changes, then the site will run and behave the same for both sites.
So trick number one is to swap the application name, based on the site being called. Now this allows for the database be different, and still run core code. But the thing is both sites will look identical at this point, so the next trick is to write an interceptor to then switch the conventions based on the URL being run. Now when you switch the conventions like handlers, views etc. You then begin to be able to skin the application, I use external views for this, so that the external view can be removed and it will fall back to the standard defined view convention.
Now that gives you a look and feel to two sites, sharing the same code with different Databases if needed.
Then in you handlers you could change the handler to suit a particular site, or it falls back to the core handler.
That is pretty much the basics, from those points you should be able to take that and run with that I had blogged about. Other solutions work well, Brads for instance, and there is more than likely pros and cons to any method.
Here’s what I ended up with
I created a website called shared as a root site, but it will never be publically consumed.
I created a website called site1 as a root site and created in it a symbolic link to the shared site
In site1 I can now use the coldbox cfc and the extension points to point to the symbolic linked directory.
If I delete all the handlers and views from site 1…IT STILL WORKS…because now “general.index” is found in the symbolic link directory rather than the site1 directory.
I have literally 100’s of sites. This methods allows for true “core” application development, ease of new site configuration and really easy customization.
thanks to both Brad and Andrew for giving me the pushes I needed.