Plugins and xwiki.cfg

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Plugins and xwiki.cfg

ebullient
I had a thought,as I sit here pulling up 1.1.1(finally), is there a
reason we have so many plugins enabled by default? 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 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).

A lot of plugins have a place where they check to make sure that
document artifacts that they need exist. 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.

THEN...

Since we have options documented in the plugin guide, we can remove
blocks like this from xwiki.cfg:

# To enable it, add "com.xpn.xwiki.plugin.graphviz.GraphVizPlugin" to
the list of plugins
# in the xwiki.plugins property.
# Uncomment and set the locations of the Dot and Neato executables
#xwiki.plugin.graphviz.dotpath=c:/Program Files/ATT/GraphViz/bin/dot.exe
#xwiki.plugin.graphviz.neatopath=c:/Program Files/ATT/GraphViz/bin/neato.exe

Same with lazlo, captcha, LDAP, etc.  Anything that can be turned off
should be removed from xwiki.cfg w/ appropriate PluginGuide docs
describing how to turn it back on.

If we *can't* turn it off, meaning that the default skin needs it,
then we should note that, eh? I think the calendar plugin, for
example, is used by more than just the EventCalendar pages (though I
forget exactly where at the moment.. but it's in the code, not in the
templates).

If the plugins become too central to wiki function, like the Packager
plugin, for instance.. it isn't a plugin anymore, and shouldn't be in
the xwiki.plugins list in xwiki.cfg.

To steal an acronym from Vincent,  WDYT?


:-P

--
'Waste of a good apple' -Samwise Gamgee
_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Plugins and xwiki.cfg

vmassol
Administrator
Hi Erin,

On Oct 4, 2007, at 3:23 AM, Erin Schnabel wrote:

> I had a thought,as I sit here pulling up 1.1.1(finally), is there a
> reason we have so many plugins enabled by default?

Yes, that's because they are core plugins. Now some of them shouldn't  
be core and should be moved out inside the xwiki-platform/plugins  
directory.

> 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?

> 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.
>
> THEN...
>
> Since we have options documented in the plugin guide, we can remove
> blocks like this from xwiki.cfg:
>
> # To enable it, add "com.xpn.xwiki.plugin.graphviz.GraphVizPlugin" to
> the list of plugins
> # in the xwiki.plugins property.
> # Uncomment and set the locations of the Dot and Neato executables
> #xwiki.plugin.graphviz.dotpath=c:/Program Files/ATT/GraphViz/bin/
> dot.exe
> #xwiki.plugin.graphviz.neatopath=c:/Program Files/ATT/GraphViz/bin/
> neato.exe
>

This should be removed anyway. The only reason it's not yet is  
because nobody has documented the graphiz plugin on
http://www.xwiki.org/xwiki/bin/view/Code/Plugins

> Same with lazlo, captcha, LDAP, etc.  Anything that can be turned off
> should be removed from xwiki.cfg w/ appropriate PluginGuide docs
> describing how to turn it back on.

Yes we all agree but it needs to be documented first on
http://www.xwiki.org/xwiki/bin/view/Code/Plugins

> If we *can't* turn it off, meaning that the default skin needs it,
> then we should note that, eh? I think the calendar plugin, for
> example, is used by more than just the EventCalendar pages (though I
> forget exactly where at the moment.. but it's in the code, not in the
> templates).
>
> If the plugins become too central to wiki function, like the Packager
> plugin, for instance.. it isn't a plugin anymore, and shouldn't be in
> the xwiki.plugins list in xwiki.cfg.

Yes I also agree with this. For me it should simply become a  
component located in the core.

The core must not depend on any plugin.

> To steal an acronym from Vincent,  WDYT?

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.

-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Plugins and xwiki.cfg

ebullient
On 10/4/07, Vincent Massol <[hidden email]> 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
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs
Reply | Threaded
Open this post in threaded view
|

Re: Plugins and xwiki.cfg

vmassol
Administrator

On Oct 4, 2007, at 6:19 PM, Erin Schnabel wrote:

[snip]

>>> 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*

ok I understand know. I was misled by the "I propose a space:  
XWikiPluginGuide".

I like documentation that comes from the source. There are only 2  
caveats:
* external contributors should be able to edit it easily somehow...
* it must be as good as the doc one would write "by hand".

[snip]

> 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.

That's nice except that xwiki.org may not be running the same version  
of XWiki as what it's documenting... :)

Anyway I'm all for it but I don't have the time to work on this right  
now...

Thanks
-Vincent

_______________________________________________
devs mailing list
[hidden email]
http://lists.xwiki.org/mailman/listinfo/devs