Files changed (4)
+.. tip:: You can use ExamplePlugin package located in :file:`contrib` directory as a starting point.
+Plugin system is besed on OO principes and uses `Python ABCs <http://docs.python.org/library/abc.html>`_ . All plugin types must implement their specific base
+class provided by MoinMoin package. All base classes are currently located in :keyword:`MoinMoin.plugin` module.
+As of now there aren't too many examples. There is an example plugin located in :file:`contrib/ExamplePlugin`.
+Also most of the plugin types have inbuilt plugins in :keyword:`MoinMoin` package itself and you can use them as reference.
+If possible new modules which are implemented as plugins shouldn't use wrappers as it's extra code and complexity which is not needed. Wrappers as they are used now is a simple way out of a lot of refactoring to make already written functionality into something that fits with the plugin system.
+For now I'm solving it by moving some of the function calls out of config. To be it seems very logical that config doesn't call mayor app functions when it's made (util functions are fine) and those are all called when config has been parsed/initialized.
+At the moment already defined themes have higher priority than those defined in Blueprint Plugin package. For example if blueprint tries to render "index.html" template and it has it in "BlueprintPlugin/templates/index.html" folder, it will still render the default "index.html" template found in MoinMoin template directory. I think I can "fix" it by changing theme code a bit (the render_template method which I already changed in themes plugin implementation). Another way is to simply prefix templates in Blueprint packages. Basically have to chose which have higher priority, as it is now, it makes sense considering how themes work.
+Currently we have no way to read it without initializing the plugin itself. This should be fixed somehow later on.
+Should be handled by plugin authors, Moin should expose helper functions and provide examples to make it easier for plugin authors.
+You can quite easily add more layers of who enables what especially if you have layered configuation.
+ * Write the rest of the wrappers, not all inbuilt functionality have wrappers. Finish writting those so all already written code can be used in configuration.
+ * Slowly move away from wrappers around already supported classes and integrate plugin system more tightly with the core code. This requires quite a lot refactoring.
+ * If new plugin types are introduced or new code "modules" which could become type of a plugin, they shouldn't use wrappers, but instead have most of the code in the plugin base class.
+ * i18n helper functions just to make it easier for plugin authors to implement i18n. (Some examples would also help)
+ * Refactor startup code, right now the code seems very non-lineral and all over the place which means there are sometimes problems accessing things which are not initialized yet. There should be a clear pipeline of what starts after what and where.
+ * Introduce a plugin container so you don't have to rewrite all the meta information if it stays the same accross multiple plugin types in a plugin package.
+ - Not tested but should be doable with most plugins, need a way to initiate the process (Could be Blueprint or Commandline Script)
+Moin is modular, many of the built in parts are implemented as plugins (or are in process of being rewriten as such).