RSS Feed

Plugin Developer Discussion

I'm currently working on a markdown plugin and it already processes the bug event text correctly, including the case and wiki auto-linking. However, since the markdown processing required the original text of the bug event I cannot re-process the HTML in the already processed array.

This has therefore broken another plugin (FB_ScratchOut to be exact); both do not work at the same time when the scratchout is processed before the markdown.

While thinking of it, I came to the conclusion that markdown processing and scratchout change the bug event in different phases. The markdown actually renders the bug event, while the scratchout only modifies it.

Only one plugin should be allowed to render the bug event, and any number of plugins should be allowed to modify it. How do you think should this be handled?

Hi Arsène-

I think your point is a good one. Let's reframe the language a little bit. The current intended behavior is that each plugin that wants to alter the display of bugevents has an opportunity to transform the html to be displayed, in order of installation. So the rgsHtml, which starts out simple, can accumulate the effects of several plugins. Then FogBugz displays the HTML from the end of that transformation pipeline. It sounds like you are seeing the intended behavior.

So (if I understand correctly) what you're suggesting is that only a single plugin be allowed to alter the actual HTML to be displayed, but other plugins would be allowed to alter the bare text of the event, or the actual BugEvent objects to be passed along? Am I missing it?

In the short term, it sounds like there might be a way to special-case by searching for the Scratchout effects in your plugin? Or maybe even generally search for HTML effects?

Finally, I'm really excited to hear that you are attacking the Markdown problem, and please let us know how it's going!

Thanks!
Brett

Hi Brett!

Thanks for the quick reply. I perfectly understand the pipeline design.

What I'm trying to say is that there should be exactly one plugin which is allowed to generate the initial HTML which is then passed through the pipeline, so that this initial HTML can be completely built from scratch instead of modifying the existing HTML. And the Markdown plugin would be such a plugin, the scratchout would be a pipeline plugin however.

I don't like the idea of making the two plugins dependent. In fact, control over the plugin execution order might be sufficient to handle this situation as a simple solution (maybe implemented in a future FB release ;) ).

Thanks,

Arsène

Hi Arsène-

Got it. Yes, we have considered the problem of plugin execution order, and have punted that to a future release; if you have an idea for how you would like it to work (e.g. if plugins would announce what priority they want in the execution order or if admins would choose the order) then I would love to hear it.

Can you talk a little bit more about what the difference would be between being a rendering plugin and simply being the first plugin in the pipeline? Would there be a difference?

Thanks!
Brett

Hi Brett,

For a start, allowing the administrator choose the order of execution in the plugins list would be enough to handle such cases because you can handle that in documentation or via reply to support requests of the customer (e.g. "Release Note: Move the Markdown plugin before any other plugin which changes bug events").

In a longer run, some interfaces should support some kind of priority mechanism (not the complete plugin, but the single interfaces which have a "pipeline" character or where the order of execution may matter).

As for this specific case, the interface would likely be the same, but only one plugin would be allowed to be loaded using it and it would be the first to be called before the other "pipeline" plugins.

Thanks,

Arsène

Hi Arsène-
Thanks for the well-thought-out analysis, as always, and I have updated our FogBugz cases around this to reflect your ideas. This is going to take a fair amount of work and testing, so we probably can't get a solution to you in the immediate future. Can you work around it for now?
Thanks!
Brett

This is going to be a bit dicey. If the API allows a plugin to declare itself last or first in the chain, then what happens if two plugins try to do this?

Some Ideas I have on the issue:

* Add an indicator to the plugin interfaces that indicates if the HTML has been modified by another plugin.

* Add an interface that allows any plugin to get a list of other plugins that have registered themselves for events that are susceptible to chaining issues.

* Come up with some best practices/standards for building plugins that play nicely and publish them on the FogBugz developer wiki.

That's why I'm advocating to make a difference between plugins that "replace" and plugins that "enhance" the HTML. Only one can "replace". If this metainformation is available, FogBugz can make sure that there is no conflict by only allowing to enable one "replace" plugin.

Hi John-
Completely agree, and thanks for the input; it sounds like we agree that it might be best if the FogBugz admin users had control over this, and if plugins could easily complain if there were other plugins that were interfering with their work. Also, agree that documentation of any solution or workaround we want to suggest here needs to be documented.
Thanks!
Brett