Though I have found some solutions to my problem, many know I’ve been trying to come up with a good way to do a SaaS application. Having gotten some methods working pretty nicely, I’d like to see if anyone has any thoughts on this structure.
When a new client comes on board, a new application template structure is created (/client1) that knows how to share code from coldbox and from SaaS so that
localhost/client1/index.cfm/users/list
would actually run code form SaaS unless the individual client1 needs to override that users.list handler.action. The basic application template for a new client would have virtually no code and pretty much just run everything from SaaS and of course /coldbox is shared for them all.
I’m testing my code on an apache server but would want it to work on IIS as well.
Any thoughts on whether or not this is possible? Since /client1 would be mapped in apache as a server root, I don’t know if this would be possible since “/” would point to /htdocs/client1…but I thought I’d at least put it out there.
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
Basically the way the post I posted here, and others basically means this.
There is a core application, that can be used with the same database or not, or can have a different look or not, skinned. This means that you can have handlers that are shared or not, so lets say Site 1 uses the core application, then site 2 extends the core application.
This is handled within the concept that I proposed in my blogs.
So handlers for instance could be set aside like
wwwroot/handlers/site1 or wwwroot/handlers/site2
And Site 2 can extend site 1, but I would be more inclined to use core code that is separated from your sites so it might be
wwwroot
-handlers
–core
–Site1
–Site 2
The idea is to change the handler convention on the fly based on what site is browsing the code.
If this doesn’t make sense, then my blogs combined will make more sense on this.