MoinMoinChat talks about a developer channel |
This page is the core page for MoinMoin development. All important resources should be linked here. If you are a newcomer please go to /GettingStarted!
Contents
General information
/DeveloperTools - which tools you could use for development
/CodingStandards - guidelines on the development process, and code layout
/CommonTasks - how to correctly do recurring tasks, like adding a config variable
/CodeStructure - a tour of the most important modules, and how to find the best place to add new code to
ApiChanges - If you want to develop extensions or port them to a new MoinMoin version, you will find some hints about changes in the API here.
/UnitTests - How to use MoinMoin testing framework
MoinMoinAcknowledgements - who has contributed
Extensions
MoinAPI/Beispiele - lots of examples in German (for a sufferable machine translation visit MoinAPI/Examples)
MoinMoinExtensions (plugins) - Contributed code
/PluginConcept - macros, actions, parsers, processors, and formatters
/CreatingMacros - hints for writing your own macro
Patches
MoinMoinPatch - Links to collections of patches
MoinMoin Concepts & Subsystems
The following pages contain the requirements, design, and docs for various MoinMoin key concepts:
/WidgetConcept - how to separate data aquisition from data display and navigation
/DatasetBrowser - displaying and browsing tabulated data
/Storage - explains the different kinds of system files and the directory layout
/WikiDom - new model for parsing, processing and formatting wiki pages
/InterWiki - How we deal with InterWiki linking
International support
If your code has user interface texts, they need to use i18n functions to easily get translated. Generally what you have to do is this:
Try to reuse other localized text already in the code if it makes sense. The user will be happy if he gets the same familiar response instead of a new little different one, and the translators will be happy too.
Release Planning
MoinMoin2.0 - next goal
/HowToRelease - steps in the release process
Repository notices
We use a Mercurial (hg) repository on http://hg.moinmo.in/ for development now, see /MercurialGuide.
- Tla / arch on arch.thinkmo.de isn't used any more.
- CVS on SF is very outdated and contains very old stuff.
Git repositories
See the https://github.com/moinwiki organisation.
Tasks for improving developer documentation
Steadily collect infos from MoinMoin wiki pages.
- Start at defining somewhat official APIs.
- Show how to best create URLs (Page.link_to etc.).
- How to use I18N features.
Discussion
What documentation should go into MoinMaster and what should rather be kept here? Benefit of MoinMaster is that this info gets distributed into every wiki. But I also think it does not make sense to have every developer doc in there? -- ThiloPfennig 2006-12-13 15:11:06
I have seen that some plugins do get outdated in some MoinMoin versions. Would it be possible to define an underlying version number for the APIs? So that rather than that we say: this is a plugin that works in version 1.3 and 1.5 we would say: This plugin works on parser-API version 0.3 ? I mean sometimes nothing changes for some extensions so you can assume that it must work on many different moin versions. Or is it so that one never can say that parts of MoinMoin guarantee to be stable so that you always have to test a plugin before you can say that it works (Well testing is always good). My intention is to make it maybe more simpler to sort extensions. Maybe the version number of MoinMoin does not make much sense? -- ThiloPfennig 2006-12-15 19:01:07