RSS Feed

Plugin Developer Discussion

In the latest version of my plug-in I wound up implementing a lot more of the interfaces from the plug-in API.

To make the code a little more readable, I tried to split it up into one class for each area (config screen, display, etc).

So rather than defining it as on giant class:
public class myPlugin: Plugin, IPluginBugEventDisplay, IPluginDatabase, IPluginStaticCSS, IPluginStaticJS, IPluginRawPageDisplay, IPluginProjectDisplay,IPluginProjectJoin,IPluginProjectCommit,IPluginConfigPageDisplay

I broke it out like this:
public class bugDisplay : Plugin, IPluginBugEventDisplay,IPluginRawPageDisplay

public class staticFiles : Plugin, IPluginStaticCSS, IPluginStaticJS

etc.

Apparently, FB doesn't like this as it complained with the following message when I tried to load it:

Plugin "FB_ScratchOut.zip" failed during load -
Each plugin assembly must contain exactly one non-abstract class that inherits from Plugin.


Is this perhaps a restriction that it would be possible to relax in the next version of the PI architecture? It sure would make my code a lot more modular.

We went back and forth on this one in the initial design of the plugin architecture.  The real trouble comes when those classes want to talk to each other, since only FogBugz has a reference to the instance of each.  We finally decided to leave it as one object, and recommend that a large plugin use its main plugin object as a simple dispatcher to its other objects with as little implementation as possible.

The Workflow plugin uses this pattern, so its implementation of IPluginProjectDisplay looks like this (apologies for the Wasabi syntax):

Public Function ProjectDisplayListHeaders()
    Return ProjectEditor().ListHeaders()
End Function

Public Function ProjectDisplayListFields(project)
    Return ProjectEditor().ListFields(project)
End Function

Public Function ProjectDisplayEdit(project)
    Return ProjectEditor().DialogItems(project)
End Function