appConstants Mach-II plugin
This plugin allows you to have a different set of application constants for each server running your Mach-II application. This is really useful if you are using version control and each developer is running the application on their local machine.
If you’re looking for a PHP version of this plugin, you can get one from Dave Spurr’s blog.
Note: this plugin requires version 1.0.10 of the Mach-II core files (although it can be modified to work with 1.0.9).
Place appConstants.cfc in the MachII plugins folder. Place this in the Mach-II configuration file:
<plugin name="appConstants" type="MachII.plugins.appConstants" />
or
<plugin name="appConstants" type="MachII.plugins.appConstants"> <parameters> <parameter name="constantsFile" value="path_to_constants_file" /> </parameters> </plugin>
The constantsFile optional parameter should be a path to your constants XML file relative to your application root (set in the properties section of your configuration file). It defaults to “/config/constants.xml”.
The constants XML file should follow the following format:
<?xml version="1.0" encoding="utf-8"?> <constants> <common> <constant name="constant_name_1" value="constant_value_1" /> <constant name="constant_name_2" value="constant_value_2" /> ... <property name="property_name_1" value="property_value_1" /> ... </common> <server name="your_dev_server_name"> <constant name="constant_name_1" value="constant_value_1" /> <constant name="constant_name_2" value="constant_value_2" /> ... <property name="property_name_1" value="property_value_1" /> ... </server> <server name="your_testing_server_name"> <constant name="constant_name_1" value="constant_value_1" /> <constant name="constant_name_2" value="constant_value_2" /> ... <property name="property_name_1" value="property_value_1" /> ... </server> <server name="your_live_server_name"> <constant name="constant_name_1" value="constant_value_1" /> <constant name="constant_name_2" value="constant_value_2" /> ... <property name="property_name_1" value="property_value_1" /> ... </server> </constants>
You will have access to the constants set up in the server section of the constants file that corresponds to the server currently running your application as well as all constants in the common block (common constant values are overwritten by server block values).
You can also specify a comma separated list of server names for a single server section (useful if several domains point to the same application).
All constants are placed in a structure named appConstants that you can access as a Mach-II property.
You can also set Mach-II properties with the property tag. These properties will overwrite any existing Mach-II properties.
Note: You can use this plugin for a single server setup. Place all your constants in the common block and don’t bother with any server blocks.
October 6th, 2004 at 11:17 pm
heh, I’ve only just started to use Mach II and I was after such a solution. Very cool and easy to use.
October 22nd, 2004 at 5:27 am
Dude, latest fix needs to be updated ie: constants = xmlSearch( defFileXML, “/constants/mode[contains(@name,':#serverName#:')]/constant” ); should be: constants = xmlSearch( defFileXML, “/constants/server[contains(@name,':#serverName#:')]/constant” ); As you no longer have the LIVE/DEV thing happening with the new :Server: version.
October 22nd, 2004 at 6:54 pm
Scott, thanks for pointing this out. I have just uploaded a new version of the plugin. Lists of servers are now handled in a much nicer way and the code is nicely commented. Let me know what you think.
October 26th, 2004 at 1:27 pm
You don’t need to set the event argument for the views in version 1.0.10 since the getProperty() method is now available.
November 8th, 2004 at 6:50 pm
Question, why wouldn’t we add the constants directly into the propertyManager rather than nesting the constants in a structure? This would allow pre-existing mach-ii applications to use this cool plugin without code rewrite. Or am I missing an implementation detail?
November 9th, 2004 at 7:48 am
Joe: This was my initial plan but I decided to group all constants in a structure to avoid name conflicts with existing Mach-II properties.
February 8th, 2005 at 7:34 pm
anyone getting this error when trying to use this plugin? Object of type class java.lang.String cannot be used as an array
February 11th, 2005 at 9:41 pm
The above error is caused by not having a matching server name entry in your constants.xml file. For instance, if you move your app to a new server and don’t have an entry in your constants.xml that matches the host name you’re using in your browser to access that server, you’ll get that very unhelpful Java error (see above comment).
August 8th, 2005 at 6:54 am
I just added your plugin to my webmail app, thanks. I did make one modification which others may find useful. I added a check that looks at the array length of servers and, if the array length is one, it assumes that the single set of constants is valid for all servers. Just email me if you would like the modified file.
August 8th, 2005 at 12:11 pm
Rob,
I have updated the appConstants plugin (version 2.2). The config file now accepts a common block for default constant values. If you write a constants.xml file with a common block but no server blocks it will behave in the way you described. I added this change ages ago but forgot to upload it to my website. I think this solution is slightly better than having a single server block as you also get a way of setting default values for all servers.
September 8th, 2005 at 6:41 pm
Martin,
I’d like to suggest an enhancement. As we know, sometimes the property applicationRoot is different on different servers. But since we are trying to extract that and use this plugin, I commented out the following.
–>
In the constants file, I added:
In the appConstants.cfc, I added some code to add that property:
// Loop over constant node array
for( i = 1; i LTE arrayLen( constants ); i = i + 1 ) {
// Insert each constant in the constants array
structInsert( variables.appConstants, constants[i].xmlAttributes.name, constants[i].xmlAttributes.value );
//NEW CODE
if( constants[i].xmlAttributes.name EQ “applicationRoot” ){
setProperty( “applicationRoot”, constants[i].xmlAttributes.value );
}
//END NEW CODE
}
So now it works. applicationRoot is free from the Mach II XML File.
Just one issue, in the Mach II XML File, I have to:
It references /intranet, because until its loaded, there is no /config… Any ideas how to bypass this?
Sami
September 8th, 2005 at 6:42 pm
Didnt show in comments:
Commented out in Mach II Xml File:
September 8th, 2005 at 6:42 pm
<!– <property name=”applicationRoot” value=”/intranet” /> –>
September 8th, 2005 at 6:43 pm
Added to constants:
<constant name=”applicationRoot” value=”/intranet” />
September 27th, 2005 at 10:25 pm
Sami: I modified the appConstants plugin to support property tags in the constants.xml file. The property tag allows you to set Mach-II properties without having to group them in the appConstants structure. I think this method is more flexible than your suggestion.
January 12th, 2006 at 3:21 pm
Hi, I ran into an issue using this plugin. Before I go into it, let me say I had it working in two separate environments without a hitch. When I deployed the app in another context, thats where I ran into problems.
The specific error related to “Can’t use java.object.string as an array”
The error was on this line:
for(i=1;i lte arrayLen(commonConstants);i=i+1) arrayPrepend( constants, commonConstants[i] );
After digging through the code, I noticed that ‘constants’ was defined as a local variable and initialized like this:
var constants = 0;
To fix this I changed the variable initialization to:
var constants = arrayNew(1);
This seemed to fix it and the app ran fine after that.
I don’t know how good of a fix this is since I don’t fully understand the plug-in. If anyone can offer guidance, I would appreciate it.
Dan Wilson
January 12th, 2006 at 3:27 pm
Dan Wilson: you usually get this error when the plugin cannot find a section for the environment’s server name. It should be better handled and your fix is probably the easiest way of fixing it. I’ll have a look and update my plugin.
However, in most cases, when you use this plugin, you should have a section for each server context. Do you not need the constants in the third environment?
January 12th, 2006 at 3:34 pm
Martin:
Thanks for the quick response. You are right, the server context is different in the new environment and needs to be reflected in the xml file.
I really have been using this to just hold my DSN information which is the same across all server contexts so this detail slipped past me.
Thanks again for the quick response.
Dan Wilson
October 11th, 2006 at 3:53 pm
Awesome plugin. I am wondering how people are accessing the appConstants in a Gateway or a Facade. For example, I have a facade that exposes methods to Flex. Flex then accesses the compoent via RemoteObject and is not aware of the Mach-ii Framework.
I can’t place the “variables.appConstants = getAppManager().getPropertyManager().getProperty(’appConstants’);” code into the init function but how do I access the constants then?
Any ideas?
Thanks,
Kai
October 11th, 2006 at 4:17 pm
Kai: you would have to pass the appConstants structure into the gateway/facade object when you create it so that it is available as a property of the object.
I’m assuming you are creating the facade inside the Mach-II framework, in which case you can pass appConstants to it’s init function. If you aren’t then I can’t see how you can access it.
October 11th, 2006 at 4:22 pm
Martin,
thanks for the quick reply. My flex application is mostly framwork agnostic, so it doesn’t invoke Mach-ii unless I run it through a Gateway that does extend the listener. Hence the constant problem of getting global variables exposed.
I’ll play around with it some more and if I find a way I will post it here.. thanks again for this very useful plugin.
Kai