In Part I, I described what I meant by saying “extension for the rule designer”. In Part 2, I am going to demonstrate how simply you can create the extension for the rule designer.
I will show you the implementation for the three steps I mentioned before here.
1. Creating your own builder strategy
The builder strategy asks the designer what element (command from toolbox) is required to be handled using our code. This class must implement two methods:
in CanCreate, we will handle the logic for the location of the command in the procedural tree or flow (in this case, it is a procedural rule, therefore it will be a tree view document). And Create will provide the return to our own command builder class named “DisplayAdvertBuilder”.
2. Create your own command builder
Our “DisplayAdvertBuilder” is the actual class that creates and attaches the command to the tree view document. It will simply be inherited from a based class.
The override methods will be the logic for different actions from the user (e.g., saving document, calling validation on the document, and so on).
3. Create your own Toolbox initializer
Now it’s time to show the command implemented using the DisplayAdvertBuilder class displayed in the tool box. To do that, the process is simply decorating the class using an attribute.
…and the attribute will provide two parameters:
- the type of document the command will appear in the tool box (TreeFormHandler)
- the actual class that draws the command on the tool box. (DisplayAdvertToolboxCommand)
And now let’s see the implementation of the command class:
This class has to implement an interface named “IToolBoxInitializer” and you’re all done!
build and compile a project class library containing these codes and reference it in your rule project ->Properties->Builders
You can find the updated version of the source for this article in the designer installer package.
Last updated May 8th, 2017 at 06:14 pm, Published April 18th, 2012 at 06:14 pm