13 Nov
2006
13 Nov
'06
4:26 p.m.
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
15 Nov
15 Nov
12:33 p.m.
New subject: [xwiki-dev] Questions on Plugin API
On 11/13/06, Vincent Massol <vincent(a)massol.net> 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
12:58 p.m.
New subject: [xwiki-dev] Questions on Plugin API
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 xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?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
6568
days inactive
6570
days old
2 comments
3 participants
participants (3)
-
jeremi joslin -
Ludovic Dubost -
Vincent Massol