For simple strings, define them within the <property> tags of the mach-ii.xml file. You can access them from a filter/listener/plugin/view by using the getProperty() method.
<cfset dsn = getProperty("dsn") />
Complex data that needs to be computed at run time can be handled by writing a plugin to initialize properties and make them available to the framework by using setProperty(). For example, you could use a bean to store application constants. Such a bean may look like:
<cfcomponent displayName="ApplicationConstantsBean" hint="An application constants bean.">
<!--- CONSTRUCTOR --->
<cffunction name="init" access="public" returntype="ApplicationConstantsBean" output="false" >
<cfargument name="dsn" type="string" required="false" default="" />
<cfset variables.instance = structNew() >
<cfset setdsn(arguments.dsn) />
<cfreturn this />
</cffunction>
<!--- GETTERS/SETTERS --->
<cffunction name="getdsn" access="public" returntype="string" output="false">
<cfreturn variables.instance.dsn />
</cffunction>
<cffunction name="setdsn" access="public" returntype="void" output="false">
<cfargument name="dsn" type="string" required="true" />
<cfset variables.instance.dsn = arguments.dsn />
</cffunction>
</cfcomponent>
Your plugin configure method can then initialize the bean and set it as a property in the framework:
<cffunction name="configure" access="public" returntype="void" output="false">
<cfscript>
variables.appConstants=createObject
("component","machii_info.model.applicationConstantsBean").init(
dsn="machii_info");
setProperty("appConstants",variables.appConstants);
</cfscript>
</cffunction>
Then your listener can use the bean in the configure like
<cffunction name="configure" access="public" returntype="void" output="false" >
<cfscript>
var appConstants = getProperty("appConstants");
variables.dsn = appConstants.getDsn();
variables.myGateway = createObject("component","cfcpath.myGateway").init(dsn);
</cfscript>
</cffunction>
Similarly, your view can get to the appConstants like this:
<cfscript> appConstants = getProperty('appConstants');</cfscript> Note that this example used a bean to encapsulate the application constants but you could implement something similar with a struct or other complex data. Note this example is only applicable for version 1.0.10 and above.
link |
2 comments
Performance should not be a problem with large XML files. There are high traffic applications with mach-ii.xml files containing 1,000 lines or more. The file is read only at startup and the size of the file should not affect the application when it is running.
link |
0 comments
Mach-II is supported on CFMX 6.1 and CFMX 7.x
Mach-II is also running on BlueDragon 6.x but note the following:
* don't use return from a <cfscript> block. Always use <cfreturn />
* Always use full qualified type names for CFCs.
* When calling a method make sure to pass all arguments defined in the method signature (even) if they are not required
* Don't pass arguments if they are not specified with <cfargument>
* Don't allow implicit type conversion unless the specified type is a parent of the actual type
Mach-II is also available for PHP. Check http://mach-ii.com/php.cfm
link |
2 comments
Being OO in nature, Mach-II better supports a loosely coupled and tightly cohesive style of development. This leads to software that is easier to maintain (and enhance).
The choice really boils down to the style of the developer/development team. If you or your team are comfortable with (and/or want to learn more about) OO design and development then Mach-II is a compelling choice. On the other hand, if you prefer to work with procedural code then Fusebox may be a better fit.
link |
0 comments
If your hosting provider already has Mach-II installed in the CF wwwroot then you should have to do nothing and it should just work.
If this is not the case and you need to install Mach-II under your site root, then you can ask your hosting provider to create a mapping to Mach-II in your site root.
If this is not possible, you can still install Mach-II under your site root however you will have to modify the Mach-II core files to search and replace "Mach-II. (and 'Mach-II.) with "the.path.to.your.webroot.Mach-II.
If you user DreamWeaverMX you can do it in a single find/replace with regex:
Replace all this:
(["'])MachII\.
With:
$1NewPathPrefix.
link |
1 comments
clearEventQueue() is a method of the eventContext. The eventContext is passed as an argument to filters and plugins but not to listeners. Therefore, there is no way to do this from a listener.
That being said, the eventContext can be accessed from the request scope. However, this is not recommended. This is an internal implementation detail of the framework and is not intended for developers to use.
Another option is to implement a custom invoker that passes eventContext to listener methods. This approach was
discussed on the Mach-ii list.
link |
0 comments
While you can modify the current event object within a listener, you
cannot halt the execution of the current event handler in a listener.
You also cannot clear the event queue from within a listener. Besides
the imposed differences in capabilities, they are also intended for
different purposes. Listeners tend to focus on interacton between the
event handler and the model, while filters tend to focus on
interaction between the event handler and the controller.
(originally from
this post on the Mach-II mailing list)
link |
2 comments
Unlike the sub-application via circuits model in Fusebox, Mach-II currently doesn't support multiple mach-ii.xml files. Others have tried workarounds that consist of havng a multiple files and going through a (XLST) processing step that combines it into one file. The recommended practice is to break the application up into multiple sub-applications each with their own mach-ii.xml file. The applications should share a common <cfapplication> name so that they share application and session variables/data.
link |
2 comments
