Originally, the sites were going to just be skins, so having the site engine change the skin on each request depending on the cgi.server_name/cgi.http_host was fine. But as the requirements changed, we realized we needed specialized code for some sites, so we decided to make each site its own application.
We first tried to implement this by having the engine add each site as a module. This would allow each site to inherit the engine's reusable code and seemed like the best solution. The main drawback to this was that we still needed a filter to change skin depending on the domain, and that we had to load all modules on application start, which did not seem best for performance reasons. (Is there a way to lazy-init modules?). So in the latest iteration, we have each site including the engine as a module instead. (This is where my previous problems with module environments came into play :D ). This has worked fine so far except that we were hoping to have the engine module include the dashboard module so that all sites would be able to access it. This apparently is not possible since modules cannot include other modules. This is not a huge problem since, for now, we can just include the dashboard on each site. I had thought about including a default set of xml files in each site as you mentioned, but it seemed an easier approach to just include one module which has all of the default code than to include all of the xml files per site. We also have a main API, separate from the engine, which is used for administration reasons and has much of the default code. This is exposed via coldspring to the engine module. For this, would it be best to use an SVN external that would include all services and their dependencies (model), or to just rely on mappings? Do you see any advantages/disadvantages to our current approach? Would it be better to forget the engine, add all that code to the main API, and include it (where needed) per site through coldsping? > Date: Sun, 4 Oct 2009 15:00:37 -0500 > From: [email protected] > To: [email protected] > Subject: [Mach-II] Re: Need help setting up multiple API structure > > > Are each site going to be their separate application instance? > Basically, this means you are going to deploy each site as a separate > application or will application have to check some data (like the domain > name) and serve something different on each request? > > If you are going to deploy each application (i.e. site) as a separate > application context, you can easily accomplish this by have a default > set of xml files (as an application base for each site) and using > Mach-II xml includes to layer in each site's customizations. You could > use SVN externals to pull in the base code and then have a repository > for each site with their customizations. > > Mixing request from multiple sites (the other option) in the same > application gets harder and messier as the application grows. That's > why it's easier to have a base set of file (that are maintained > separately and therefore you can upgrade the base and have your > customized sites get upgraded) and then layer in the customizations via > Mach-II XML includes and there respective additional files (listeners, > filters, models objects, etc.). > > Best, > .Peter > > Po said the following on 09/30/2009 11:52 AM: > > SETUP: mach-ii 1.8, coldspring, and transfer > > > > I currently have an application which is used as the backbone for the > > administration of multiple e-commerce sites. This contains many > > services that will also be used in the actual sites, not just for > > administration. However, each site can potentially have specialized > > services, event-handlers, listeners, filters, plugins, and properties > > that are not part of the backbone's API. These will be mainly handled > > by another application which will be the direct "engine" for the > > sites. Each site will in turn be it's own application since some of > > them may require further specialized code. > > > > [MAIN API] --> [ENGINE API] --> [SITES] > > - MAIN API contains most of the services > > - ENGINE API exposes MAIN API services and adds specialized services, > > event-handlers, listeners, filters, plugins, and properties needed for > > the sites as well > > - SITES further specializes if needed > > > > Does anybody have a similar setup or any recommendations as of how to > > best reuse the code following best practices? > > > > > > Thank you. > > > > > > > > > _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to Mach-II for CFML list. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/mach-ii-for-coldfusion?hl=en SVN: http://greatbiztoolsllc.svn.cvsdude.com/mach-ii/ Wiki / Documentation / Tickets: http://greatbiztoolsllc.trac.cvsdude.com/mach-ii/ -~----------~----~----~----~------~----~------~--~---
