Extension:RecordAdmin

Legacy: This article describes a concept that has been superseded in the course of ongoing development on the Organic Design wiki. Please do not develop this any further or base work on this concept, this is only useful for a historic record of work done. You may find a link to the currently used concept or function in this article, if not you can contact the author to find out what has taken the place of this legacy item.

This code is in our Git repository here. Note: If there is no information in this page about this code and it's a MediaWiki extension, there may be something at mediawiki.org.

The Record Administration extension forms the heart of our Wiki Organisation system.

To export all the templates used by RecordAdmin, see wiki articles packages

RecordAdmin 1.0

For the last couple of years since RecordAdmin 0.0.1 was created in October 2007, we've kept the version numbering to 0.x to indicate it's experimental nature. Now halfway through 2010 we've been using it for our own project management and organisation and made a number of decisions about how version 1.0 should work. Here's a summary of our findings:

1. Rather than use a category of templates to determine the record-types, 1.0 uses the titles in the NS_FORM namespace (i.e. all templates having an associated form are considered to be record-types). This is more logical since it's the form that determines the data types and field names within a record.
2. The record creation and editing should be done from the standard edit view rather than from a special page. This will be far simpler for the user since we could then remove the "properties" or "edit with form" action.
3. The special page is hardly ever used for searching since usually records are arrived at via a portal query. Since the special page would no longer be used for editing or creation either, it seems that it would be best for it to be removed from the main extension and made into a separate sub-extension like RecordAdminIntegratePerson and RecordAdminCreateForm.
4. There should be allowed to be any number of records in a page as long as they are all of different types. And in fact as far as edit view goes, it shouldn't even have a problem with multiple of the same type. The records should all be at the beginning of the article and be removed from the standard edit box. We need to ensure that the method we use for this doesn't interfere with FCK or MCE.
5. We decided that for organisational purposes, GUID's are the best approach for naming, but I think it's still important to be able to add record types to any title, so we still need to handle the redirect issue.
6. Exporting needs to be handled as an API method, also allowing the standard lists such as JSON for AJAX queries
7. RA is very query-heavy, but a lot of the time it would be easily possible for RA to cache results and know when revisions occur which invalidate the cache - the very least of simply invalidating them all when any record changes would still offer a massive reduction in processing.
8. Record-table content could be allowed to load via AJAX after page load if not cached

Editing

The main edit area and each record type form are hidden and expandable one at a time, the revealed one is settable in query-string. Record types can be added or removed dynamically and show their forms above the main textarea, the record wikitext is removed from the textarea and added on-save. The query-string can also include default values to use in the event that the record doesn't exist and so is being created. The parameters to do this are to be called preload::TYPE::FIELD since they operate in a similar way.

We need to hook into the MW edit view and render record forms if the content contains any record template calls. Also a create record drop down needs to exist which can AJAXly add new records in to any article. All the existing record template calls must be removed from the wikitext textarea. The showEditForm:initial is probably the best hook for adding record forms to the edit view.

When an article is saved, any posted record forms must be converted into wikitext and prepended to the article text before the save occurs. The hook to use for this is MW:Manual:Hooks/ArticleSave.

Caching

caching uses either current cache layer or bag-of-stuff to store query result list and rendered queries by key. Keys include all the record type, filter parameters and user. Rendered results also include non-filter parameters such as template. Cache directives can be included in the queries to allow additional environment attributes to add to the key, or to mark as uncacheable. Invalidation occurs on-save and applies to all queries involving the same record-type, so recordtype must not be hashed.

API

• query: returns either a standard API list of results, or rendered HTML
• create: the new "public form" method allowing records to be created without any login, edit form or saving required so bots and AJAX can do creates easily

AJAX

• Record table queries could render non-cached content as an AJAX request so that the page can always load fast even when it contains non-cached data.
• Maybe even revamp the livelets extension

Rendering performance improved

One of our clients has some complex record tables which became extremely slow when there were more than 100 rows of data in the resultant set. After analysing the execution of the slow queries it turned out that over 90% of the processing time was in the renderRecords method. The problem was that the initialisation of the wiki parser takes a lot of resource, and it was being initialised once for every cell of data in the table. The problem was fixed (see diff) by breaking the render loop out into two passes, the first to build a single block of wikitext for the whole table with delimiters for columns and rows, and the second to render the table drawing from the pre-parsed cell data rather than calling the wiki parser directly.