Re: [xwiki-dev] Questions on Plugin API

Hi there, I have some questions on the xwiki plugin API: 1) In XWikiDefaultPlugin it seems the classname field is never used. It's actually never set AFAICS. I also don't understand the "if" in the following method: public void setName(String name) { if (!name.equals(className)) this.name = name; } BTW this will probably fail at runtime as className is not set anywhere I can see.

2) I can see in XWikiPluginManager.addPlugins() that it calls addPlugin(classNames[i], classNames[i], context). Thus it seems "className" and "name" will always be the same. Why the have both?

3) Why do plugins need to know their own class name? I mean I understand plugin class names are required to instantiate them but why pass their className in the XWikiDefaultPlugin constructor?

4) Why do we pass the context in the XWikiDefaultPlugin constructor as it's not used at all (it's not assigned). Actually all plugin API methods all accept a XWikiContext object... I believe the best would be to pass the context in the constructor and remove the context in the plugin API method signatures.

5) In XWikiPluginInterface what is virtualInit() compared to init(). The name is not really self-explanatory and there's no javadoc... It seems it gets called in one place only, in XWiki.updateDatabase(), but I don't understand it's called there.

6) In XWikiPluginManager there are several methods like this one: public void virtualInit(XWikiContext context) { Vector plugins = getPlugins("virtualInit"); for (int i=0;i<plugins.size();i++) { try { ((XWikiPluginInterface)plugins.get(i)).virtualInit(context); } catch (Exception e) {} } } However as virtualInit() is defined in XWikiPluginInterface, it'll always be present in any plugin. So why check and not instead loop over all plugins?

7) What is XWikiPluginInterace.flushCache() for?

8) I can see two methods in XWikiPluginInterface: begin and endRendering. My first thought was that plugins could contribute to rendering a page but that's not it as these methods are not returning any content. It seems they are only hooks so that actions be can performed before and after the rendering is done. Is that correct? I haven't been able to find any plugin implementing these methods. Are there any examples?

9) Could you explain XWikiPluginInterface's commonTagsHandler(), startRenderingHandler(),outsidePREHandler(),insidePREHandler() and endRenderingHandler()? I think I have a general idea of what they're for but I'd like more details. Actually I'd like to write the javadoc for them but I need the info to put there.

10) Same question for downloadAttachment().

11) I see in all plugins that we implement the getPluginApi() like this: public Api getPluginApi(XWikiPluginInterface plugin, XWikiContext context) { return new ZipExplorerPluginAPI((ZipExplorerPlugin) plugin, context); } My question is why do we create a new object every time the API is called. It doesn't sound efficient. As there's only one plugin instance created for every plugin, why isn't the *API class instantiated in the plugin constructor method?

12) I personally don't like too much the way that all plugins have to implement all plugin methods even those that they do not use. I think it would be better to define different extension points (as interfaces for example) and have plugins implement the interfaces/extension points they need only. This would have several advantages: - it would clearly show what a given plugin is contributing - we wouldn't have to create a XWikiDefaultPlugin class with empty methods. A user implementing a plugin interface should see in his IDE the methods he has to implement. With XWikiDefaultPlugin as all methods are already implemented it's hard to know/understand. - I also think we should have more extension points for plugins. Like the ability to hook in the storage logic. For example if we want to implement a SVN plugin that saves docs to SVN by committing them.