So I had a great idea — why not just use DokuWiki as the story manager?

The idea hit me after some nagging issues over how to italicize text, and UTF-8 versus Latin1. I had attempted to install tinymce, but then realized this was a super-heavyweight solution that really did not hit many of the targets I was aiming at (since I also needed a database solution). Roll your own had issues. I wanted to, for example, store metadata. Then I started using flat-files for things like frequency analysis, since a lot of this would be easy to offload to a script file with a low priority and io priority. And then run on cron if need be.

The thought briefly entered my mind to re-start the MyWiki project as a subset of Kongzi Online. As a story manager.

Then it struck me — all the lessons I had learned from the NSV project appeared in front of me for Kongzi.

  1. Use DokuWiki as the story manager.
    • This means, use DokuWiki as the story editor and displayer.
    • The worst I can do is ?do=export_text and include it directly in the system I have now.
    • This means all I need to do is have a link to the dokuwiki page.
    • This means I can use indexmenu or nspages dokuwiki plugin to auto-generate a list of stories.
    • This means I don’t need to store anything in a database since dokuwiki will manage everything for me.
    • This means I can autocreate different incremental analyses of a file and store them in the appropriate namespaces.
    • Including POS tagger data.
    • This means I can create templates to display stories and allow the user to see things in light mode, dark mode, etc. as they wish.
    • This means I can easily include italics et cetera.
  2. Use DokuWiki as the story viewer.

    The thought briefly entered my mind to re-start the MyWiki project as a subset of Kongzi Online. As a story manager. And then I remembered how well DokuWiki served as the MyWiki which already existed.

    • So how to organize stories? There will be a directory which only contains stories in plaintext?
  3. Use a custom reader
    • A likely solution.
    • This means I can use strip_tags() in PHP to only allow certain tags.
    • It also means I can store metadata right on the page and read it in.
    • Author: name
    • url: (insert url here)
    • source:
    • notes:
    • or, not include metadata. And it will be read in and processed but hid from the user.
      • This is really convenient!

This looks like a very interesting way to do things.

Now, wait a moment, what if I used DokuWiki to store dictionary information as well? Oh… interesting….

The concept of flatfiles, or incremental updating vs. calculating on every update (such as, pulling thousands of entries from the database every load of the story library) is something which probably has to go. Having this done automatically by a script which “simply” creates a static (DokuWiki) page, and/or then creates static tables of data culled from the wiki in plaintext, is a solution far too tempting to ignore.

By Serena

Leave a Reply

Your email address will not be published. Required fields are marked *