ColdFusion, WordPress, Flash & other web things


appConstants Mach-II plugin

File name:
appConstants.cfc
Version:
2.3
Last updated:
27 September 2005
Requirements:
Mach-II 1.0.10, CFMX 6.1

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.

Download appConstants.cfc

21 comments

  1. #1: Scott Barnes Says:

    heh, I’ve only just started to use Mach II and I was after such a solution. Very cool and easy to use.

  2. #2: Scott Barnes Says:

    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.

  3. #3: Martin Says:

    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.

  4. #4: Christopher Town Says:

    You don’t need to set the event argument for the views in version 1.0.10 since the getProperty() method is now available.

  5. #5: Joe Baarsch Says:

    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?

  6. #6: Martin Says:

    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.

  7. #7: Kim G Says:

    anyone getting this error when trying to use this plugin? Object of type class java.lang.String cannot be used as an array

  8. #8: Kim G Says:

    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).

  9. #9: Rob M Says:

    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.

  10. #10: Martin Says:

    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.

  11. #11: Sami Hoda Says:

    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

  12. #12: Sami Hoda Says:

    Didnt show in comments:

    Commented out in Mach II Xml File:

  13. #13: Sami Hoda Says:

    <!– <property name=”applicationRoot” value=”/intranet” /> –>

  14. #14: Sami Hoda Says:

    Added to constants:
    <constant name=”applicationRoot” value=”/intranet” />

  15. #15: Martin Says:

    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.

  16. #16: Dan Wilson Says:

    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

  17. #17: Martin Says:

    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?

  18. #18: Dan Wilson Says:

    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

  19. #19: Kai Pradel Says:

    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

  20. #20: Martin Says:

    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.

  21. #21: Kai Pradel Says:

    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

Leave a comment