AX2012 Extension framework generation wizard

Many of you might have come accross the Extension Framework while venturing in AX2012 for some years now. Personally, I use this pattern a lot in my code as the benefits of using it are obvious:

• Your extensions are more decoupled from the standard code which reduces upgrade work
• Your code will be more robust and cleaner
• Implementing extra different behavior is easy if the pattern is already in place
• And let’s admit it, we have indeed become lazy and do stuff the easy way. Result is code that wouldn’t be written if it were in another language

Before jumping into the wizard, you should read the following posts giving a nice overview of what this pattern is all about.

• http://daxmusings.codecrib.com/2014/11/ax2012-extension-framework.html
  This gives the most understandable overview how to create all of the elements needed.
• http://blogs.msdn.com/b/ax_gfm_framework_team_blog/archive/2012/11/13/the-microsoft-dynamics-ax-2012-extension-framework-part-1.aspx
• http://blogs.msdn.com/b/ax_gfm_framework_team_blog/archive/2012/11/13/the-microsoft-dynamics-ax-2012-extension-framework-part-2.aspx
• http://blogs.msdn.com/b/ax_gfm_framework_team_blog/archive/2012/11/13/the-microsoft-dynamics-ax-2012-extension-framework-part-3.aspx

After using this pattern so many times, I wanted to share a tool that allows you to specify some of the needed information and then creates all of the elements for you. This allows you to use this pattern without having to complain about the ‘overhead’ it might be causing you. So let’s jump in then.

First, before all else, we need an enum that contains the different behaviors that will be available. In our sample we will use two methods of calculating, adding and multiplying. Do not forget the none value so that we can easily see if the type has been passed on.

Then opening the wizard and clicking next, it shows the second tab page allowing you to specify the following information:

• Attribute class name
• The XML comment class name description of the attribute class
• The system element name of the enum
• A variable name that will be used for your enum when generating the pattern

When ready, move to the third tab and fill in the class name and XML documentation description for the following objects:

• The interface
• The base class
• The factory class
• The parameters class

With all of this filled in, click finish and you are ready with your end of the bargain. Now sit back and let the wizard take care of the following part. The result should look like this:

• The attribute
  

• The interface
  

• The abstract base class
  

• The parameters class
  
  
  This class is required to get around what I call the one hickup with this pattern. Since it uses reflection to get to the class containing the right attribute, there is a makeObject() involved. This will in it’s turn call the new() method of our behavior classes thus preventing us from passing different sets of parameters for different behaviors. I usually solve this by creating a parameter class containing the possible parameters in behaviors. You can fill in the parameters for the behavior you need at that time and leave the ones your do not use empty. The wizard by default creates the object with one dummy boolean and corresponding parameter method.
• The factory class mainly contains a factory method to create the behavior

So as you can see, the wizard created the most of the stuff containing the plumbing with enums, attributes, …

The only thing we have to do to get things up and running is creating the behaviors ourselves since the wizard does not know what we want to do. So to implement our two behaviors, we need to do the following:

• Add parameters to the parameter class
  We will be adding or multiplying two integers, so let’s add these.

• Add a calculation method to the interface / abstract base class
  

   

• Create the two calculation behaviors.
  To do this, create two classes that each use an attribute and each implement the doCalculation method. The ‘add’ behavior is show below.
  

Now that everything is in place, we can use it so let’s add and multiply the numbers.

This should output the following:

And there we have it, just calling the same code with different enums changes the behavior of the calculation. And the best part, from now on, if a developer wants to extend this and write other behaviors, the only thing he need to do is add and enum element and write a class that passes that enum to the attibute!

The source code of the wizard can be found here