Locations Database/Further Development

Make creation an Actor instead of a Module
DONE

Make Actors for each user actions on the maintenance side
Actors are classes derived from abstract base class LdbActor.

Each Actor provides a standardized trigger interface for processing web requests, mainenance scripts and maybe later even for api web requests. Also, it manages the displaying of module data, its own web forms etc.

It deals with modules via standardized module methods.

Actors for:
 * Actions that modify module data:
 * create - DONE
 * delete - DONE
 * undelete - DONE
 * edit - DONE
 * undo edit - DONE
 * merge - DONE
 * unmerge - DONE
 * rename
 * Actions the don't modify module data:
 * diff - display differences between revisions.
 * perm - change permissions

Improve structure of user input processing
Make clean processing steps when receiving user input. This is done by Actors. Each Actor provides the following hooks:
 * beforeAction - directly before an actions will be started.
 * beforeCheck - before validate user input. Provide read/write access to received form data for extensions. Also, allow extensions to block further processing.
 * afterCheck - after validate user input. Provide read/write access to tatus object(s) and received form data for extensions. If appropriate, also temporary internal data derived from user input. Give extensions a chance to update the status before further processing or rejecting, respectively. Allow extensions to block further processing.
 * beforeDone - user input has been validated and action will be done, but further processing might be necessary.
 * afterDone - processing of user input done, but all DB data is still untouched. Ready for saving to DB. Provide ro access to set of (presumably) differences in hooks.
 * beforeSave - Just tell extensions that saving begins.
 * afterSave - Just tell extensions that saving has been completed.
 * afterAction - directly after the action has been completed, but before display.

During the check phase, only things needed for user input validation are done. The DB remains strictly untouched. After having completed, the decision is made whether the requested action will take place or not. Last chance for extensions to block the action is to change the status in the afterCheck hook wich is run at the very end of the check phase.

During the do phase, all modifications that will take place are prepared to be ready to save. The DB should still remain untouched, however, this is not always possible. An exception is the creation of locations and aliases. The corresponding DB table entries are made during this phase, but locations are still marked as disabled and aliases are not linked to any location. We need this in order to provide the corresponding IDs in modification forecasts. When this phase is completed, i.e. when the afterDone hook is run, extensions can ask the actor for a complete preview of all modifications to be performed. There are three seperate previews for creation, modification and deletion of locations. All follow the same sceme: an array keyed by locID, holding arrays keyed by module name and LdbModChange objects as values.

During the save phase, all modifications prepared during the do phase will be saved in the DB. There must not be any side effects.

DONE (except beforeAction and afterAction hooks)

Implement Loading of Modules on Demand (LOMOD)
Allow modules to determine whether they want to display no section, section 0 only or all sections when page is loaded. All missing section can be loaded via Ajax whenever need by the user.

Let users define in personal settings which modules they want have displayed when page is loaded.

DONE, but works only for normal display, not for synopsis

Add an abstraction level for checking user input for modules
First attempt was made with SmartModule, but this is not used in trunc.

Provide an interface for modules for generalized precheck of user input. Modules define which data types they expect in form fields. Also, let them give a range for numeric values, etc. This way, some of the annoying standard checks need not to be recoded in each module.

DONE

Use null revisions for pseudo wiki pages whenever possible
Once a pseudo wiki page exists, it should be possible to add all further revisions as null revisions. But this still has to be verified.

DONE Seemed not to be a big deal.

Make sure field loc_deleted can be dropped from table location
DONE - Observe if there will be error messages.

Rename ModIsIn to ModMain
This is a bigger deal as all DB table rows in moddata need to be adapted.

DONE, so far, but I still do expect strange surprises.

Insert a dummy non-location in DB table
Introduce a dummy non-location into DB table where all non-enabled locs are isIned. Maybe move world from ID 0 to ID 1 and use ID 0 for noLoc. World should be the only enabled loc with isIn noLoc. This makes queries simpler.

DONE - now watch for error messages.

Try to abolish wired alias redirects
Check out if all MW needed functionality is possible without having tons of formal MW redirects form alias titles to the Ldb:Location_nnn page and its talk page, respectively. If possible, only the Ldb:Location_nnn pages and its talk pages should survive as we need them for MW revision management.

What still does not work without alias redirects:
 * search

Reduce LdbSpInput and LdbInput to a minimum
LdbSpInput is still a dino left from the early days. Reduce this to a simple entry point for web requests.

The idea of LdbInput has become obsolete after having implemented Actors. Try to remove this class completely.

Add new, more specific, classes if necessary.

Provide hooks for extension specific display
Provide hooks for extension specific display in Modules and ModLikeDisplays. Allow adding HTML as well as JS:
 * beginSect - For ModLikeDisplay and Modules: section 0 and other sections
 * endSect
 * Maybe others whenever appropriate.

Try to reduce live processing of derived input data to a minimum
Check if processing of derived user input data can be outsourced to a deamon process in order to speed up wait time for users when making modifications.

Problem: Current extensions need to see the database in both states, before and after the modification.

Better consistency for secondary IsIns
See LocDB About primary and secondary IsIn for what to do.

Todo
Add HieraRelLoc into the core and use DB table iwsubloc whenever possible.

Display also secondary IsIns when clicking on the tree dots at the end of the BC trail.

Display whether a location is:
 * 1) clean or unclean.
 * 2) regular or P2.

For UP2, add a list of overlapping children that also shows the common children of overlapping sublocs.

Throw a warn message when user input makes a location turning from clean to unclean.

Provide generalized interface for modifying modules by maintenance scripts
Modules should provide a list of HTML form field names (keys) that maintenance scripts can use for reading/writing module specific values.

In case of (structured) list data, provide a naming sceme for the keys.

This should be managed by the corresponding Actors.

Split the huge JS file into handy parts
Make a better controling structure that allows modules or extensions to add their own JS as needed.

XML import/export
Define a set of XML tags appropriate for the LocDB. Keep as close as possible to MediaWiki import/export XML.

Improve map display in module Geo

 * Prevent strange jumps.
 * Control box does not disappear when hiding the map.
 * Maybe add an update buttom for subloc display
 * Maybe, add a layer for all touching (atomic) locations.

Fix uneven BEGIN-COMMIT pairs in DB calls
Probably on application side. Find out where the additional COMMIT comes from.

Changes in DB definitions
Aliases never should be modified. Create a new row when title differs. Set las_loc to NULL when a location losses a title.

Drop field loc_deleted. This is obsolete already for a longer time.