September 27, 2015 by Alistair Deneys
Revolver has been release under the MIT license.
Revolver 3 supports Sitecore versions 6.4 through to 8.1 and you’ll find the release packages either on github at https://github.com/codeflood/revolver/releases/tag/release%2Fv3.0 or on the Revolver downloads page at codeflood.
It’s now Open Source
I first announced plans to make Revolver open source 3 years ago at the Sitecore Symposium AU conference in 2012. The reason I didn’t jump straight in and make Revolver open source at that time was because I wasn’t happy with some of the code quality. The module code itself wasn’t too bad. What I was more concerned about what the test suite. Yeah, that sounds a bit odd, but I’ve written so much and presented over the years about unit testing with Sitecore that it would have been embarrassing to let that test code out in the state it was at the time.
In fact, it was through development of Revolver I discovered and refined many of the unit testing techniques I’ve written and presented about. The embedded ASP.NET NUnit test runner was initially developed inside Revolver, springing from my need to run my unit tests inside the Sitecore context so all the APIs would work.
So as you can imagine, the test code was in need of a little finesse. This was one of the biggest drivers for delaying the open source release.
And then along the way I changed a few things in the module. And this leads me into the first new feature.
Auto Mapping for Command Arguments
Revolver has always supported the creation of custom commands. But command developers where left to parse the input provided by the user out of the arguments passed by the Command Handler. It worked, but it seemed like this was something that could be handled automatically.
And it can. Revolver 3+ now allows command developers to add properties to their command classes and decorate those properties with attributes to allow the Command Handler to map the arguments to the properties. This makes development and testing of the command much easier. You’ll find more about this at http://www.codeflood.net/revolver/extension/commands/.
So with this new command model in place, I had to convert all core commands over to it. And that was no small feat. I would still be converting those commands if it wasn’t for help from Dan Solovay and Mr. Throwing Exceptions himself, Mark Stiles who both helped out in the command conversion and unit test updates for the commands.
Revolver has had subcommands for a long time. This allows one to take the output of one command and pass it into another as an argument. This was very handy but sometimes made you feel like you had to work backwards on a problem. Take for example the task of updating a field value based on it’s current value. Write out this process:
- Get current field value
- Perform the update
- Store the value back in the field
Using subcommands to do this you worked backward, because the outputs of the previous command must be passed to arguments of the next command. So the outer most command is the ‘set field’ (
sf) command, and not the ‘get field’ (
gf) command as you’d expect. This is what it would look like:
sf text < (replace < (gf -f text) (revolver 2) (revolver 3))
Command chaining allows us to work forwards, so it allows us to more easily follow the process we listed above. Here’s what this would look like using command chaining:
gf -f text > replace $~$ (revolver 2) (revolver 3) > sf text $~$
This is much more readable. As you can see above, subcommands use the
< token and command chaining uses the
> token. Inside a chained command the previous command output is available through the
~ (tilda) environment variable.
You can read more about subcommands and command chaining in the Revolver documentation: http://www.codeflood.net/revolver/usage/combiningcommands/.
Scripts from Disk
You can now write your scripts in text files rather than having to write them in the core DB. Most often developer will be working in the master DB. Having to switch over to the core DB just to write a script was frustrating, so now you can write them in text files on disk. By default Revolver will look for scripts on disk in the
\sitecore modules\Shell\Revolver\Scripts folder. Script files should have an ‘rs’ extension. Plus, having scripts in text files makes it much easier to put those scripts into source control.
This is afforded by the new Script Locator implementation. Read more about script locators over at http://www.codeflood.net/revolver/configure/scriptlocator/.
Some New Commands
Of course I’ve thrown a few new commands into this release as well. These are commands I found myself needed day to day.
cache command allows listing caches, their contents and clearing them.
wfc command allows listing available workflow commands for an item and executing them.
Use the help system to find out more about these commands (in Revovler type ‘help’ and the command name).
Aliases and Command Binding
The previous implementation of the bind command always worried me a little. It allowed users to rebind core commands to new names. If a developer did this then scripts written by others may not work if they use the default command name.
So the bind command also got an overhaul. To allow developers to use commands by name they feel more comfortable with bind now supports creating aliases to commands. The command will be available on the default name and also the new alias name.
Read more about aliases in the Revolver documentation at http://www.codeflood.net/revolver/usage/aliases/.
Session Initialisation Scripts
In previous releases init scripts had to be placed under a certain item in the core DB. With the introduction of the script locators I needed a way to allow init scripts to be located in any locator. So it was easier to use a naming convention for init scripts.
We now have a global init script, init scripts for each Sitecore role and individual users init scripts. Read how they work together and their execution order in the docs: http://www.codeflood.net/revolver/configure/initscripts/.
This has been quite a sizable release with lots of change for the better, and a realisation for a long standing goal of mine, to get the module open source.
In case you missed it above, I just want to point out again, huge thanks go out to Dan Solovay and Mark Stiles for their help in this release.
Now accepting pull requests! (just make sure the test suite passes first)