When this site was vandalized, I lost the newer instructions on how the query language works. The result is that the instructions are missing all the newer features I added after about August 2004, and the LARP Schema is behind the times. I need to bring both back up to snuff.
Along with generally fixing up the query documentation that had been lost, I need to add the newest mechanism, which allows a page query to have clauses of the form "World==Garden". Also, page queries can now include variable references in the query, and the restriction can include PAGENAME, so you can have page queries like "% %IS_A% %==PAGENAME" -- this is wonderful for allowing us to have really generic display templates.
One consequence of having schemas is that I find that I now really want to be able to share those schemas between Wikis. I have a fairly complex schema for LARP development, and it's a pain in the tuchus to have to copy all of it each time I add a new LARP. (Worse, maintenance is almost impossible.) So it would be lovely to have some mechanism that allows me to share pages between multiple Wikis -- to have a separate Wiki that represents a common subset of all of them.
Dealing with permissions in this environment wouldn't be easy -- we want to be able to edit the shared schema from any of the constituent Wikis. Maybe it has its own config, with its own special permissions, so that only certain users can edit those?
Idea inspired by jikharra: instead of having the parent link at the page header that goes to the base class, have a chain of links showing the ancestry (probably in small print below the title?), each of which goes to a listing of that class. That would probably be more useful, most of the time.
It would be convenient to have a variable form (like "% %#VARNAME% %"), that means "the number of VARNAME" thingies. This would allow me to easily tally, eg, how many archetypes I have.
It would be useful to have a page property on page X that simply means "redirect to page Y", to make name changes easier.
When editing, there is a Save button. It would be useful to have a Save and Continue button as well, which would simply submit the current changes and return to the editing state.
Currently, all values for a given property wind up getting read in, in their entirety. This could potentially be a problem, since one can easily see a single property table winding up a full megabyte.
The tentative solution is to only include the beginning of each property value in the file. The first 100 (50?) bytes of the values would go into the property file, plus a tag that indicates that the rest has to be fetched from the actual file. This means that short properties would still be read in a single pass, but long ones don't bulk up the property file. It trades off a few more small file accesses against some very large ones.
I'll decide to do this, and figure out the tuning values, once it begins to become an issue.
The system needs a lot of hammering and error-checking. One consequence of properties is that there are now many more ways to create an illegal page. We should be detecting that illegality at edit time, and return appropriate errors, telling the user to try again.
I should also hammer on inheritance cycles, and make sure you can't send the system into an infinite loop. The code is intentionally designed (sometimes a bit obliquely) to ignore cyclic inheritance -- things are generally structured so that cycles will automatically terminate. But this really hasn't been tested yet.