MoinMoin: Admin2009/ClassStructure

Legend

• - Potential controversial issue

• - This shall work. Unless someone actively objects, this shall happen as it is.

Install script

Files:

* defaults.py

Sane defaults for install locations, per platform. Kept separate to provide a direct, non-intrusive way to modify the defaults (by developers). It also contains the basic tools required for path validation and such.

* installer.py

Installer script, the workhorse of the installer. It handles the install vector (other than the defaults), the installation process itself (not administrative farmconfig/wikiconfig settings). The earlier plan to put wiki migration in this file as well was ditched so that the code could be made more 'pythonic'.

* install.py

Install UI. Works with python CGI. Needs to be reimplemented for python WSGI. Both CGI and WSGI will be supported.

* htmlsnips.py

Helper for install.py, takes care of actually generating the html. right now it just has a bunch of HTML like strings. Similar to utils/web.py, but much simpler since its a one-time-use thing that should be shipped with the barebones installer.

Classes:

* DefaultTargets

Contains the default installation vector. Initialization of the class returns a dictionary object with paths populated.

* Targets

Contains the paths the installation is supposed to take place in. Derives from DefaultTargets. Is also capable to exporting to and importing from a file (file format?, serialization?).

* Installer

Keeping things in the pythonic "everything is an object" way, the installer itself is a class. It contains all the functions. It creates a Targets object, handles its population, validation, etc. The apache config edits go in here as well.

Admin interface

Basic Layout

• Intermediate class between wikiconfig and config functionality.

• Interface is completely unaware of wikiconfig settings set independent from it. There is a potential issue here since wikiconfig.py can override interface settings. Proposed way of solving this would be to deactivate settings that are directly affected by current contents wikiconfig.py, and allow them to be edited only if the corresponding lines are removed from wikiconfig.py

• Consider having it derive from wikiconfig instead, with the option of "Don't enforce settings on this parameter". The knowledgeable can disable the admin system from enforcing its settings, the not-so-knowledgable cant break their install by damaging wikiconfig.
• The interface is going to be kept separate from the config system save for two exceptions :
  • The interface can write to a serialized config file, probably using Config Parser
  • The interface can read the existing wikiconfig to determine possible conflicts.
• All explicitly listed options in multiconfig.py, along with a few (http, ldap, moin) auth methods will be supported. 'Pythonic' option strings and

generation of options via python code itself will _not_ be supported at this time.

Files

• MoinMoin/config/multiconfig.py
• wiki/config/autoconfig/autoconfig.cfg.sample
• wiki/config/autoconfig/autoconfig.cfg.allsupported

=== Classes ==

• Admin Config
• Admin Page