Feedback on EmptyOoPlugin

this plugin doesn't actually do anything it is the start of an attempt to provide a more object oriented (and more automatic) framework for developing plugins.

for example, the base plugin constructor reads the debug variable for you. when you call the writeDebug() function in the class, it checks to see if the debug flag is set and behaves appropriately.

by defining any of _commonTagsHandler, _startRenderingHandler, _outsidePREHandler, _insidePREHandler, or _endRenderingHandler methods (the same names as the standard plugin interface, except with a preceeding underscore) in your plugin class, the constructor automatically creates the appropriate glue to your class' methods (you can also call the base class methods (e.g., $self->SUPER::_commonTagsHandler( @_ );, as the base classes provide logging/debugging code)

initPlugion() becomes very simple; just the object constructor, really: %CODE{"perl"}% sub initPlugin { my ( $topic, $web, $user, $installWeb ) = @_; $thePlugin = __PACKAGE__->new( topic => $topic, web => $web, user => $user, installWeb => $installWeb, name => 'EmptyOo', ); return 1; } %ENDCODE% (although i'd like to clean this up, too)

i haven't converted an real plugins to this architecture; i'm sure i'll find many holes when i do. ( like writeWarning(), among others )

even though this isn't done, i'm posting it because i may not have much TWiki time available in the near future

among many other improvements, i'd like to have the constructor create a hash of all the plugin variables automatically by parsing the plugin topic, but that hasn't happened yet...)

-- WillNorris - 14 Oct 2003

p.s. too bad the BeautifierPlugin isn't installed

-- WillNorris - 14 Oct 2003

efficiency:

Some (maybe offtopic comments): if you design a new plugin system, it may be worth it to make an efficient one: off the top of my head:

• do work at install/uninstall, not at runtime. For instance, to register hooks, have the plugin installer (in perl) patch the list of called functions in a file. This could then even be done entirely from wiki, allowing for a "one-click-install" mecanisms.
  Apache installs work this way (directly edit the httpd.conf)
  This would avoid having to execute all the plugins on all page loads, which doesn't scale.
• tend towards a more "lazy" code: for instance, do not do anymore:
  for all plugins: search/replace all their %FOO% vars...
  but rather:
  _search the regexp once: %([A-Z0-9])+%, and then look for the match in a table of registred names, or maybe better (with mod_perl you want to load code rather than execute it) eval the function twikiVar_\1
  This way we could have a system where having 100s of plugins would not slow down the system

-- ColasNahaboo - 15 Oct 2003

Some wording changes by MattWilkie on 16 Oct 2003, thanks Matt! (I am not a native speaker so feel free to correct me without even commenting - Colas)
-- ColasNahaboo - 16 Oct 2003

I uploaded a different approach for OO plugins in PluginOOApi, along with some metrics for performance.

-- RafaelAlvarez - 09 Sep 2004