Tags:
create new tag
, view all tags

EmptyOoPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on EmptyOoPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Feedback on EmptyOoPlugin

this plugin doesn't actually do anything smile 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 frown

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 frown

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

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2004-11-20 - MartinCleaver
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.