FreeLists / dokuwiki / [dokuwiki] Re: Roadmap for next release

["Chris Smith" <chris@xxxxxxxxxxxxx>]

> On Mon, 5 Sep 2005 21:09:20 +0100
> "Chris Smith" <chris@xxxxxxxxxxxxx> wrote:
>
> > Hi,
> >
> > Some comments ...
> >
> > Related to your plugin specific js/css point.  I think
> there needs to
> > be a way for a plugin to tell dokuwiki that it wants to put
> code into
> > other parts of the page.
>
> Yes that could solve some of the problems. That would mean my admin
> plugin should use a non-standard named scriptfile and add it itself to
> the head section of the page?

Yes.

> > I think there is a need for a plugin prefix or some sort.  Is
> > "plugin_<plugin type>_" really that bad?
>
> I didn't meant the name of the plugin. I just found
> $this->plugin_locale_xhtml() a little bit cumbersome. Shouldn't be
> $this->locale_xhtml() be enough? Or assuming an admin plugin
> will always
> produce xhtml $this->locale() should be okay as well. Or am I misssing
> something here?

Ah, ok.  I misunderstood.  There is no special reason for those functions to
be prefixed by plugin_.  I can do a patch to change them.

>
> > Can you explain what you mean by fall back to getInfo if no menuname
> > is set? That to me says the plugin is improperly made.
>
> Well I started with your skeleton plugin (and didn't do the
> second part
> of the tutorial) and wondered why there wasn't anything in the menu.
> Would have been nice if it had shown the plugin's name (maybe with a
> FIXME behind) to signalize I'm on the right way...

Oops, my bad, it sounds like the skeleton is not up to scratch :)

If we are talking about mechanisms to assist in plugin development, can
anyone think of a way to allow certain plugins to be loaded without the "@"
prefixing the plugin include statement.  With the '@' in place, any PHP
errors are hidden from the developer.  Taking the '@' off for all plugins
can lead to lots of warnings for files not found as plugin_load attempts to
load the plugin files from different locations.

> > Even if you change away from "$lang", there is still the possibility
> > of clashing with other plugins.
>
> Hmm shouldn't $this->lang always be in it's own namespace (of the plugin
> object) and never clash with other objects? Or did I misunderstood
> something here?

That's my understanding. So everything should be fine with localisation side
of things.  Is it worth copying the same set of functions into the base
syntax plugin class?

Chris


-- 
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist