Daniel Peter Lepage on Tue, 20 Jun 2006 09:11:24 -0500 (CDT) |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
Re: [s-d] What news? |
> On Mon, 2006-06-19 at 22:58 +0200, Joel Uckelman wrote: >> It would be easy to write a GraphViz script to represent the House, >> since >> it sounds like the House is an undirected graph. (GraphViz produces >> beautiful output in a variety of formats.) >> > > I was taking a look and there is a GraphViz extention here: > http://meta.wikimedia.org/wiki/GraphViz > So we could actually have the map editable from the page. None of the graphs on that page show up in my web browser (firefox). > As for parsing the rules and such here is how it would work. > > The unformatted rule page would look like this: > > > The rules as of 8/10/2008 > > ==Section 1== > > {{Rule|Wonko has the power|1.1|3|2|Wonko has the power to do anything he > wants}} > > {{Rule|No Whtp|1.2|0|2|Rule 1.1 is invalid}} How well does this work for longer rules? At one point, rule 301 was well over 15 pages long, with many subsections. We've also had rules with embedded ASCII diagrams and other weird things. Also, is there any easy way to extract single rules? What if I want a page to show me all rules containing the phrase "Wonko has the power"? > And what the templating system would do is is format it the way we want > and fill in the blanks with the data set there. I think css does the > same sort of thing but I may be wrong. CSS lets you tell the web browser what formatting info to attach to various XML tags. It's a similar concept, but the rules would be stored in XML. > Also I think you can easily do a database dump into xml but i'd have to > check. That would be useful for backing things up, but I doubt we'd want to make use of it for viewing etc. because it would require keeping two copies of all data, one in the wiki and one in the XML dump. The system I really wish we had is this: We have a program written in Python using the Python Database API, so that it can be run on top of a number of different database programs (MySQL, PostGreSQL, ODBC, Oracle, etc.). The program knows some number of types of documents; types can be added, removed, etc. by anyone with appropriate permissions. Each type describes the relevant fields, so the type "rule" has a title and a body, and maybe a list of keywords or a Chutzpah value or a timestamp, and the type "room" has a name, a description, an ordinances field, a list of exits, a list of occupants, etc. Every document also has a revision number, possibly some number of old revisions, a book, and a section. Various tools for managing these exist, but they're all clearly written solely as tools for tracking the information itself, *not* for display. Separate components then provide the interfaces that expose the functions of these tools to, for example, a wiki engine. Tools written for MoinMoin would format the data using MoinMoin's engine and display it accordingly, and provide forms that fed into the various features of the underlying document tracker. Other tools written in PHP could provide the same features through a MediaWiki instance, etc. There would be generic document viewing tools that could view any document, search by various fields, etc. We would also be able to add other viewers where relevant, such as one that reads in all Room data, builds a dotfile for the House, and renders it into an image map and displays that. This system would be extremely flexible, would allow all sorts of extensions to be coded on, and would make the game really easy to administrate. Is that feasible? I know that there are nomics with systems kind of like this - Nomicron certainly has the "general purpose document tracking" down. Or should we just stick with something more limited but simpler, like a wiki? -- Wonko _______________________________________________ spoon-discuss mailing list spoon-discuss@xxxxxxxxx http://lists.ellipsis.cx/mailman/listinfo/spoon-discuss