I'm currently working on an upgrade to both the Mach-II and ColdSpring frameworks for our core engine. We are currently running Mach-II 1.5 and ColdSpring 1.0. The ColdSpring plugin has been tweaked quite heavily for our own purposes so I'm going to look more into using the new ColdSpring property in Mach-II 1.8 RC 1 at a later date. In the meantime, I have a question regarding the deprecated mach-ii.cfm bootstrapper.
Current Architecture
There is a base site which exists as an exception to all other sites and is located at webroot\websites\base. This website contains all global functionality for the engine and is structured like any other Mach-II website. However, this website is not designed to be requested directly but to be included by individual websites as a module within their own mach-ii.xml file. This allows one of our websites to contain a much simplified Mach-II.xml file that inherits the base site events, but also allows additional functionality to be defined in place of the base site or as an extension of it.
webroot/websites/base
webroot/websites/site1
webroot/websites/site2
etc etc
All requests for the websites are channelled through the index.cfm file which in turn includes the necessary Mach-II bootstrapper - mach-ii.cfm. The Application.cfc component for each website extends base.
How to include the Application.cfc bootstrapper?
As the mach-ii.cfm bootstrapper is deprecated in Mach-II 1.8 and replaced with mach-ii.cfc. The base Application.cfc would extend MachII.mach-ii. Each of the websites would then inherit all the methods of the base application component and mach ii. As each of these sites need to have their own mach-ii.xml config file, what’s the best way to set this up? This is an example of what I've been looking at for the websites Application.cfc which extends base, which inturn extends Mach-II. Perhaps somebody might be able to point me in the right direction!
<cfcomponent name="Application" output="false" extends="websites.base.config.Application">
<cfscript>
this.name="site1";
this.foldername="site1";
</cfscript>
<cfset MACHII_CONFIG_PATH = ExpandPath("../../../websites/site1/config/mach-ii.xml") />
<cfset MACHII_APP_KEY = this.name />
<cfset MACHII_CONFIG_MODE = -1 />
<cfset MACHII_ONLOAD_REQUEST_TIMEOUT = 100 />
<cffunction name="onApplicationStart" output="false" returntype="boolean">
<cfset super.loadFramework() />
<cfreturn true />
</cffunction>
<cffunction name="onRequestStart" output="true" returntype="boolean">
<cfargument name="targetPage" type="string" required="true" />
<!--- handle the request --->
<cfif findNoCase("index.cfm", listLast(arguments.targetPage, "/"))>
<cfset super.handleRequest() />
</cfif>
<cfreturn true />
</cffunction>
</cfcomponent>
5 responses to “How to utilise the Mach-II bootstrapper?”
Comments now closed
Jan 7, 2010 at 6:02 AM Ok so a brief follow up to this.
As my base application extends Mach-II and my sub application extends base, I obviously can't call super.loadFramework or super.handleRequest from within my sub apps Application.cfc. These need to be called, from within the base apps Application.cfc onApplicationStart and onRequestStart methods respectively.
The problem I have is that the current architecture uses a number of request variables in some Mach-II plugins and other cfc's. These request variables not set until the onRequestStart method in the base Application.cfc duplicates the application variables.
The current architecture may prove problematic because the use of the request variables throughout the application violates encapsulation principles.
Anyone have any thoughts?
Jan 13, 2010 at 3:55 AM Your Application.cfc uses multiple levels of inheritance so calling super.xyz() is calling the method exactly one level up. The only time you need to use super is when you need to call the method in the CFC the current CFC is inheriting from and the method name is the same. For example, if you method name is getFoo() and you want to call the method getFoo() in the parent CFC. Otherwise, you can just leave off the super.handleRequest() etc.
Actually, your example is override the onApplicationStart() and onRequestStart(). By default, Mach-II provides these methods in the boostrapper (as of 1.6). You could delete these methods entirely from your example as what you have there is exactly what the bootstrapper provides for you.
I invite you to join the Mach-II Google Group. It's a great place to get questions answered by the our large community and to help out the framework by becoming involved in open source. I'd post a link, but I think your blog might reject it. No question is too trivial for the group -- we don't bite ;-)
Welcome to Mach-II!
Best,
.Peter
Team Mach-II -- We're Community Driven!
Jan 13, 2010 at 3:58 AM BTW, we released Mach-II 1.8 RC2 on December 27th, 2009 -- I'd suggesting pulling that down if you are still working with RC1. Just has a couple of fixes for defects that were logged by the community. The more eyes and brains the community provides -- the better the Mach-II releases.
Jan 13, 2010 at 4:25 AM Hi Peter,
Well thanks for taking the time to answer my blog post! I should really have posted this to the Mach II google groups but actually wanted to use it as an excuse to start blogging.
I have some more questions, so will probably post them over there and then blog here any solutions or other questions to the wider community.
Loving Mach-II! It's been my first foray into using frameworks and it's been quite a journey but one I've enjoyed nonetheless.
David
Jan 13, 2010 at 11:00 AM David, glad to be of help. Our wiki is set to public anonymous edit. I highly encourage you to not only blog your items, but if you are willing share it on the wiki. There many people that blog about Mach-II and then contribute to the wiki by filing in missing parts or adding in entire solutions to problems. We're trying to make the wiki a centralized place to get documentation on Mach-II. In it's early years (2003-06), Mach-II's documentation was spread mostly over a bunch of disseparate blogs. Since blogs cannot be edited except by the owner, it was great for new information but a less successful way for our as a Team to disseminate documentation. Hope to see you blog more on Mach-II (and hopefully I'll see you on the wiki as well). Let anybody on Team Mach-II know if you need help with the wiki -- editorial, where should this go, what do you think about this solution, etc.
Best,
.Peter