Discussion for FogBugz Plugin developers
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 "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.
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()
Public Function ProjectDisplayListFields(project)
Public Function ProjectDisplayEdit(project)
This topic is archived. No further replies will be accepted.Other recent topics