Guidance for Module Developers

I have just returned from two days of meetings in Redmond with the Microsoft "Patterns and Practices" group.  This group is responsible for Enterprise Library, the various Appliation Blocks (we use the first version of the Data Application Block in our SqlDataProvider classes), and more recently the "Software Factories".

Shaun and I were invited to spend some time with them to discuss areas where we could work together.  They were interetested in our feedback regarding challenges working in the "Web-Client" space, and we were interested on whether they could help us understand (and implement) current and upcoming MS technologies.

One thing that I discovered, and feel we could make use of, is in the area of Guidance (for Module Developers).  What is Guidance?  Simply put, it is help provided in a way designed to provide "Best Practices".

Guidance can come in a number of forms, and the "Patterns and Practices" (P&P) group have integrated Guidance into the Developer environment.  This is done by first creating content in a help format that can be integrated into the developers Visual Studio Help. 

However this is extended by also providing a wide-range of Wizard-based extensions to the template architecture.  In the DotNetNuke Starter Kit we provide Project Templates and Item Templates.  These provide limited code-generation capabilities, based on template substution. 

Visual Studio provides a rich "Add-In" capability to extend these concepts.  Unfortunately, the Visual Studio Add-In API is COM based and somewhat difficult to use, so the P&P team have created a managed .NET layer to interact with Visual Studio.  On top of this framework, they can now build sophistacted wizards to gather information from a developer and autogenerate code.  Most wizards, once they have finished then automatically load the relevant help-content into a Visual Studio page, and add a "Guidance" window with "next steps" suggestions.

How can we take advantage of this?

We can simplify the task of module developers by building similar wizards. 

For instance, a new Module Wizard might collect a list of properties (name/types) that the module is managing, and automatically build the Info class, the standard CRUD Controller methods, the IPortable (Export/Import) methods, the ISearchable methods, the abstract DataProvider, concrete SqlDataProvider (or other data provider) methods and the CRUD Sql scripts.

Then if the developer requires a new Info class to manage, we could provide an Add New Entity Wizard that does the same thing to add the new classes/scripts (and possibly automatically adding Foreign Key relationships).

The developer can then focus on his/her own business logic requirements.

The possiblities are endless (the only problem is resources to accomplish the task).