MyPlugin, you will need to create a
index.cfmfile. Then zip these together as
x.xis the version number of your plugin.
MyPlugin.cfcmust contain a method named
init. This method must set a variable called
this.version, specifying the Wheels version the plugin is meant to be used on (or several Wheels version numbers in a list) and then return itself.
index.cfmfile is the user interface for your plugin and will be viewable when clicking through to it from the debug area of your application.
MyPlugin.cfc, and Wheels will inject it into Wheels on application start.
(access="public"). If you have functions that should only be called from the plugin itself, we recommend starting the function name with the
$character (this is how many internal Wheels functions are named as well) to avoid any naming collisions.
mixinattribute can be set either on the
cfcomponenttag or on the individual
application, global, none, controller, model, dispatch, microsoftsqlserver, mysql, oracle, postgresql.
environmentattribute. Using this, you can tell Wheels that a plugin should only inject its functions in certain environment modes. Here's an example of that, taken from the Scaffold plugin, which doesn't need to inject any functions to Wheels at all when it's running in production mode.
pluginsfolder. Each plugin then has its own expanded subfolder. If a subfolder exists but has no corresponding zip file, Wheels will delete the folder and its contents.
?reload=trueto the URL.
application scope. One example of a stand-alone plugin is the PluginManager. If you check out its view code, you will see that it calls itself like this:
@parameterlines give a helpful hint to the user
box.jsonis required for new plugins. Read the Publishing Plugins chapter for more details on that. One advantage is that CFWheels now includes the version and meta data for each plugin when there's a
box.jsonfile, should you wish to use it for storing ancillary data and settings.
2.xmeans you can add a
.jarfile, and it will be automatically mapped into the
this.javaSettings.loadpathssetting when the application starts.
2.xis the tighter integration with command-line tools such as Commandbox. We can take advantage of the new testing suite JSON return type and the new CFWheels CLI in Commandbox 2.x to easily build a Travis CI test. It's perhaps easiest to just show the
.travis.ymlfile - this goes in the root of your gitHub plugin repository, and once you've turned on testing under Travis.org, will run your test suite on every commit.