FreeLists / dokuwiki / [dokuwiki] Re: language files in action plugins

[Ben Coburn <btcoburn@xxxxxxxxxxxxx>]

On Feb 4, 2007, at 14:14, Martin Tschofen wrote:

> That's it. Of course. I looked at the file structure before but it 
> just didn't sink in. I added a line to the wiki page, just in case 
> somebody else doesn't grasp this.
> It's time to release my index plugin. Thanks again...martin
>
> On 2/4/07, Chris Smith <chris@xxxxxxxxxxxxx > wrote:Martin Tschofen 
> wrote:
> > > I'm stuck with this problem. I'm sure I'm missing something simple
> > <snip>
> > > class action_plugin_full_index extends DokuWiki_Action_Plugin {
> > >
> >
> >
> > Don't use an underscore in the plugin name, its used as a separator
> > between different elements of the class name. The localisation 
> > routines
> > are looking for the language files (and config files) in
> > lib/plugins/full/lang/ (lib/plugins/full/config)
> >
> > Check out http://wiki.splitbrain.org/plugin:file_structure for more 
> > details.
It would be nice if there was some valid character to represent spaces 
in a plugin name (both class and plugin folder). It's a minor annoyance 
now, but it is only going to get worse as all the good (one word) names 
get taken -- thanks to all the new action events. More worrying is that 
this will increase the likelihood of plugin names colliding (causing 
problems for users).
I guess the real issue is with "discovering" the plugin class name. If 
plugin class names were not hard-coded, '_' could be used in plugin 
(folder) names. I think something like this should work...
// [simplified pseudo-code]
$plugin_class = null;
include("<path to plugin>/$type.php")
// where a "new style" plugin name is defined in $plugin_class by the 
plugin
if (is_null($plugin_class))
    $plugin_class = $type.'_plugin_'.$name;
$DOKU_PLUGINS[$type][$name] = new $plugin_class;

This also allows for other globally unique class naming styles to be 
used in the code. For example PEAR style "CMS_Doku_Plugin_S5" or even 
Java style "org_splitbrain_doku_plugin_S5". The effective plugin name 
should still be looked up from the folder name (at runtime) and never 
hardcoded. This should allow conflicting plugin folder names to be 
changed without disrupting the plugins. There are some other details 
that need to be adjusted in the base plugin class to handle this in a 
transparent and backward compatible manner but I think it's possible.
Note: The GUI does not show the effective plugin name. Really it should 
show the plugin.getInfo()['name'] value, so the effective name could be 
any non-conflicting folder name.
Does anyone see any major issues I've overlooked?

Regards, Ben Coburn


-------------------
  silicodon.net
-------------------

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