On 10/4/07, Vincent Massol <[EMAIL PROTECTED]> wrote:
> 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.
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*
> > 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
