Merlin: One Module to Rule Them All?
This is part five of a series on Merlin. I recommend you read from the beginning.
Since testing my integration strategy would require a bit more code than I was ready (or willing) to write, I was determined to bite off the smallest chunk possible and verify things along the way. (Remember, this was just a personal project, not on company time) My first test was to see if I could use the same CSModule more than once. Just by looking at the code I could see that CSModules were keyed by their name, not type, but I wanted to be sure. So I just copied the declaration of an existing CSModule, changed its name, restarted my local installation, and made sure nothing too crazy happened. Thankfully, the test worked!
You see, my idea was simple. I was planning to write a single CSModule (possibly the last CSModule) and make sure that it understood how to parse an embedded rule (stored as metadata), wire itself up to the proper events (still needed a solution here), and then wait to be fired (part of the existing eventing system). Thinking ahead, I came to the conclusion that I could also create a single Job (possibly the last Job) and reuse much of the same code. So now rules could potentially be triggered by either an event or a timer.
Since the test worked, I felt the only real work left would be to create a simple UI that would allow an admin to put together the rule parts and output some simple xml into the communityserver.config file. Furthermore, by storing the rule inline, we could easily ship pre-configured rules and allow folks to share their rule configurations, rather than force them to walk thru the UI to create some basic rules. (Not a bad side-effect)
With this mini-success in hand, I had enough confidence to begin writing some code. After all, this thing might actually work! Nevermind the looming contest deadline that was quickly approaching... (continued)