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. That's all for now :-) Note: Once I get the answers to these questions I'll document the code. Thanks -Vincent ___________________________________________________________________________ D�couvrez une nouvelle fa�on d'obtenir des r�ponses � toutes vos questions ! Profitez des connaissances, des opinions et des exp�riences des internautes sur Yahoo! Questions/R�ponses http://fr.answers.yahoo.com
On 11/13/06, Vincent Massol <[email protected]> wrote:
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. Yes, it should be investigated.
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?
Yes, it should be investigated.
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?
Yes, it should be investigated. ;-)
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.
All the plugin extend this. some plugin need the context to be constructed. But I agree we can remove it from the XWikiDefaultPlugin
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.
virtualInit is the initialization when we are in virtual wiki environment. updatedatabase is executed at the initialization of every wiki.
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?
We call only the plugins who implement it.
7) What is XWikiPluginInterace.flushCache() for?
when we call flushCache on xwiki, we call it also in the plugins
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?
yes it is look at the plugin fileUpload.
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.
Ask to ludovic, I've never used it.
10) Same question for downloadAttachment().
look at the zip explorer plugin and imageplugin
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?
the API of the plugin is created at every request of the plugin. it contains the context of the request.
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.
I totally agree. jeremi
Vincent Massol a écrit :
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.
I don't remember enough if it has any impact to change this.. The plugin name is used for finding the plugin the the xwiki.getPlugin() function.. That's the most important thing that needs to be maintained.
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?
To have 2 plugins with the same className potentially.. but it's probably not correctly implemented
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?
I don't remember.. they probably don't
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.
Can't do that.. The plugin is initialized once and shared for good.. The context allows the plugin to access the context of the request.. You can't use the one from the initialization when you want the one from the current request. The plugin wrapper is intiantiated for each request. This one can keep the context as a property. The constructor has the context because some plugins might need it.
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.
virtualInit is called once per JVM execution per Virtual Wiki. It allows to plugin to make sure it has the data it wants in the wiki database that it is run on.
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?
I don't think so. The getPlugins() checks if the plugin has a local implementation, not an heritated one. At least that's the objective.
7) What is XWikiPluginInterace.flushCache() for?
Allow plugins to flush any caches they might have.
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?
Yes they can but also perform cleanup after the request. We have found some problem with that when pages are included in other pages. It makes multiple call to endRendering happe. And endRequest would be better
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.
Old stuff it should go away
10) Same question for downloadAttachment().
Ask Jeremi
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?
This is done once per request when the plugin is requested. It allows to wrap the plugin and the context object to make it easier for users to write to the plugin API (no context to be passed everywhere).
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.
This idea was to have plugins extend XWikiDefaultPlugin to allow to not implement them in the plugin code itself. If there is a better solution, let's use it.. However we have to be careful not breaking everything.
That's all for now :-)
Note: Once I get the answers to these questions I'l Cool
Ludovic
l document the code.
Thanks -Vincent
___________________________________________________________________________ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
participants (3)
-
jeremi joslin -
Ludovic Dubost -
Vincent Massol