4 Oct
2007
4 Oct
'07
6:19 p.m.
On 10/4/07, Vincent Massol <vincent(a)massol.net> wrote:
Well, I was hoping that the plugin could maintain it's own doc inside
itself. That way, it never is out of date. Deploy the plugin, get new
doc. *poof*
Hi Erin,
On Oct 4, 2007, at 3:23 AM, Erin Schnabel wrote:
I'm not even sure
anyone knows how to use most of the ones that are enabled. AND, as
they're plugins, they shouldn't be on or enabled unless they're
actually needed.
I don't agree here for 2 reasons:
1) enabling a plugin isn't currently straightforward
2) you're talking about the standalone distribution which has an
already made xwiki.cfg and that's fine since it's meant to work as is
with a default choice of plugins and a default config in general. If
you're talking about the WAR distribution, the xwiki.cfg is just an
example and is expected to be modified by the user. I propose a
space: XWikiPluginGuide.
Each plugin would have a page in the guide describing: a) how to
enable the plugin, b) what options are used by the plugin, c) how to
invoke and use the plugin, and optionally d) who wrote the plugin and
the version information (which that document could retrieve via a
getVersion, getAuthor, or whatever call back to the plugin).
I'm not sure I understand. We already have this on xwiki.org on
Code.Plugins. Are you suggesting that this should be bundled inside
the default wiki? If so we need to revisit the whole area of bundling
documentation in the default wiki XAR since right now we're not
bundling any and instead pointing users online at xwiki.org. A lot of
plugins have a place where they check to make sure that
document artifacts that they need exist.
I don't understand that. Could you explain it more? From the feed plugin:
public BaseClass getAggregatorURLClass(XWikiContext context)
throws XWikiException
{
XWikiDocument doc;
boolean needsUpdate = false;
doc = context.getWiki().getDocument("XWiki.AggregatorURLClass",
context);
BaseClass bclass = doc.getxWikiClass();
if (context.get("initdone") != null)
return bclass;
bclass.setName("XWiki.AggregatorURLClass");
needsUpdate |= bclass.addTextField("name", "Name", 80);
needsUpdate |= bclass.addTextField("url", "url", 80);
needsUpdate |= bclass.addTextField("imgurl", "Image url",
80);
needsUpdate |= bclass.addDateField("date", "date",
"dd/MM/yyyy
HH:mm:ss");
needsUpdate |=
bclass.addNumberField("nb","nb",5,"integer");
String content = doc.getContent();
if ((content == null) || (content.equals(""))) {
needsUpdate = true;
doc.setContent("#includeForm(\"XWiki.ClassSheet\")");
}
if (needsUpdate)
context.getWiki().saveDocument(doc, context);
return bclass;
}
> One of the things they would
> check is if "PluginGuide.pluginname" exists, where pluginname is what
> they return in response to getName(). If "PluginGuide.pluginname"
> doesn't exist, they'll create one, setting the title, etc. They
> *could*, in theory, either add a field to that document or use the
> document's inherent version to decide whether or not the document
> should be all out replaced at some later point, so that when the
> plugin is updated/loaded, the page is updated.
>
> The plugin code itself is the repository of all knowledge as far as
> what xwiki properties it understands, how the methods should be
> invoked, etc. That way, if I want to know how to use the feed plugin,
> I can just go to PluginGuide.feed, and find out.
This does imply creating docs in the local user install (perhaps w/ an
option). Which would mean, for example, that if you enabled the plugin
on xwiki.org, you'd get the latest doc (under PluginGuide.pluginname
rather than Code.Plugins), w/o having to update two separate places.
I'm just not understanding the first part of this email about the
PluginGuide stuff. The rest matches my thinking too. We're just
missing tech writers to do the job.
Does that make it any clearer?
--
'Waste of a good apple' -Samwise Gamgee