Plugin Developer Discussion

Discussion for FogBugz Plugin developers

Plugin must contain only one non-abstract class

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


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

Plugin "" 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.
John Fuex Send private email
Friday, August 14, 2009
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
David Fullerton Send private email
Tuesday, August 18, 2009

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz