One of our goals for metaPost was to create an infrastructure that makes it as easy as possible to create providers for the metaPost offline publishing infrastructure.  One of the first things Dan Gilleland provided feedback on when he contacted us was the fact that the naming conventions used in the SDK were not as intuitive as they could be.  He also suggested that we simplify the API and use interfaces to categorize the publishing features in ways that make it as easy as possible for module developers to create a basic metaPost provider.  Well, that's just what we did.

To get us started, I'll lay the foundation by explaining the metaPost infrastructure.  And what better to use for an explanation than a graphic?

The main point of this graphic is that metaPost is comprised of 3 distinct pieces. 

• metaPost Publishing Engine - This piece controls the translation between modern publishing protocols such as MetaWeblog, WordPress, MovableType and Atom Pub (Not yet supported).
• metaPost Provider Infrastructure - This is the heart of the SDK.  It is in this part of the metaPost platform that the following DNN specific publishing interfaces are defined: IPublishable, ILinkable and IWrappable.
• Individual metaPost Providers - Individual metaPost providers are created for each DotNetNuke module which is designed to manage published content.

So, why should I care about creating a metaPost provider for my module?  That's a question that I'm sure is on your mind if you're a third party or custom module developer. There are a number of great reasons.  Here are a few:

• Easily Add Offline Editing - By implementing the IPublishable interface in your module, you open your module up to a whole new world of offline publishing clients that are designed to use a variety of publishing protocols.  The best part is, you don't have to master the details of any of these publishing protocols.  All you do is focus on implementing a publishing service layer designed specifically for DotNetNuke modules.
• Saves Time - While you could take the time to write your own MetaWeblog API, you'll find that getting the API to work with the publishing clients on the market is time consuming.  By implementing the IPublishable interface which is designed specifically for DotNetNuke modules, you save valuable development time.
• Adds Features - In addition to saving time, when you implement the IPublishable interface in your module, you offer users of your module the opportunity to make use of either the Community Edition or the Professional Edition of metaPost.  The Community Edition is free and the Professional Edition adds publishing features like this¹, which make it fun and easy for your content providers to add Web 2.0 styled content.  And this is just the beginning.  As more features and more providers are added to the metaPost infrastructure, your customers will be glad you added support for offline publishing through metaPost.
• Follows Good Enterprise Design Patterns - This should be a whole post in and of itself, but I'll just say this.  If you're developing a new content related DotNetNuke module, I would recommend starting with the IPublishable interface to serve as a Service Layer for your application.  It's common in DotNetNuke to implement a Domain Model through the development of controller objects, and this is a good step, but adding a service layer by implementing IPublishable opens your module to many more integration scenarios.

How Much Work Is Involved?

That may be your next question.  If so, great question.  We'll give you the details and you can decide.  Until we complete a Visual Studio template, the best way to start is to find a similar module.  What do I mean by this?  Well, of the current providers, there are a few distinct classes.

• 1 Module = 1 Post - This is the case with the Text/HTML and the Magic Content providers.  These providers are written to allow content providers to edit the content of the module.
• 1 Module = Many Posts - This is the case with the following modules:  Blog, News Articles, FAQs, etc.
• Hybrid - Some modules, such as the Expandable Text/HTML module support both concepts.  If your module needs to support both concepts, then this may be a good module to use as a starting point.

In addition, there are features that your module may need.  See the list of providers which make use of these features to determine whether the provider you've chosen for a starting point is a good fit.

• Hierarchical Categories - News Articles
• Keywords - Not implemented by providers in SDK (Contact us for suggested implementation) 
• Use of Categories for Feature Settings - News Articles
• Multi-Page Support - News Articles
• Summary - Blog, News Articles
• Comments Setting - Blog
• Auto-Pingback Setting - Blog

Once you've found a good fit, you have a couple of choices:

• Separate Assembly - Create a separate assembly which contains your provider implementation.  The advantage to this approach is that you can send the provider to IT Crossing and we'll include it in the distribution of metaPost.  It's free publicity for you and your module to have this provider listed on our site.
• Included in Module Assembly - You may also choose to implement the IPublishable interface inside a class in your module.  You could even implement the IPublishable interface in your controller class, thereby combining the concept of a service layer with that of a domain layer.

If you chose to create a separate assembly, then

• copy the contents of the directory for your provider from the SDK zip file
• rename the project file (eg. MetaPostProvider.FAQ.csproj --> MetaPostProvider.Announcements.csproj)
• open the project in Visual Studio
• in the Solution Explorer in Visual Studio, you would rename FAQprovider.cs to AnnouncementsProvider.cs. 
• remove the reference to DotNetNuke.Modules.FAQs and replace it with a reference to your module, in our case DotNetNuke.Modules.Announcements.dll.
• make sure there are references to both DotNetNuke.dll and ITCrossing.MetaPostProvider.dll
• rename the Assembly name and Default namespace in the Assembly tab of the Project properties.
• remove or update any entries in the Build Events tab of the project properties.

Regardless of whether you've chosen to create a separate assembly, you'll want to

• follow this up with a global find and replace on the term FAQ.  In our case, we'll replace with Announcement.
• check to see if any stored procedures need to be created.  For example, if you're starting with the FAQs provider, there is a stored procedure called from the GetModuleIdFromItemId private procedure that will need to be updated for your provider.

Next, open the source code file for your provider, in our case AnnouncementsProvider.cs.  You should see something like this:

The section titled IPublishable Members contains the code that we'll need to change for our implementation and the section titled Private Procedures..., yep, that's where you'll include your private procedures.

Implementing your provider is straightforward.  Of course, we'll help you through that process, but that will be in the next part to this post.

Until then, feel free to Contact Us to get your copy of the metaPost SDK, and, as always, thanks for your interest in metaPost!