Go to the FreeLists Home Page Home Signup Help Login
 



[dokuwiki] || [Date Prev] [02-2007 Date Index] [Date Next] || [Thread Prev] [02-2007 Thread Index] [Thread Next]

[dokuwiki] Re: language files in action plugins

  • From: Chris Smith <chris@xxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Mon, 05 Feb 2007 12:04:57 +0000
Ben Coburn wrote:

To utilise generalised localisation and configuration functions you'll need to store the directory name along with the class name.


Isn't it the other way around? It looks like the class name is only needed to instantiate the class instance. The getPluginType, getPluginName, and getPluginCommponent methods could be rewritten to pull their values from member variables that would be set when the instance was created.

So getPluginName would look something like this:
function getPluginName() {
    if (is_null($this->pname)) {
        list($t, $p, $n) = explode('_', get_class($this), 4);
        return $n;
    } else {
        return $this->pname;
    }
}

And the plugin loading code would gain some lines like:
$DOKU_PLUGINS[$type][$name]->pname = $name;

Maybe my coffee hasn't kicked in yet, but I don't see how, from the code above, the generalised routines will know what folder to look in for the language and configuration information. [ Right now, the generalised routines do cheat. They use getPluginName() where they should really use getPluginFolder(), however I can not think of a mechanism for the inherited class routines to determine where the actual class resides. ]

If it is, it may be worthwhile working out something to handle versioning at the same time. Users of helper plugins should be able to ensure they get the version they need.


The idea here is to get away from "magic" or restrictive naming conventions. How do you see this helping with versioning? Would adding a well documented getPluginVersion method to the plugin base class help? Maybe have it return a simple int to avoid version name parsing issues?


Some how a user of a helper plugin needs to be able to request a helper plugin object of a suitable version. Where as most code inside DW doesn't care a jot about the actual name, a helper plugin will need to lookup a plugin by name and version and grab the object if it exists. To me this implies some core DW code to handle

$oHelper = dw_getHelperPluginObject(<plugin name>, <component name>, <requested version>);
or $oHelper = dw_getHelperPluginObject(<helper plugin name>, <version>);

which presumably would be need to examine dw's array of loaded plugins. It'd be handy if that array contained version information. I guess for each plugin of correct name, the request could generate a call to the helper to see if it was compatible with the requested version.

Cheers,

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




[ Home | Signup | Help | Login | Archives | Lists ]

All trademarks and copyrights within the FreeLists archives are owned by their respective owners.
Everything else ©2007 Avenir Technologies, LLC.