Doku’s Complex Document Problem

Dokuwiki is not designed for complex documents, such as anything other than a plain layout with headings. So, when you want to do something like columns, you need a plugin (like WRAP) — but then, headings don’t work inside the columns.

The solution is probably to use the inlinejs plugin, with PRELOAD, HTML and JS blocks. But then we still won’t be able to use dokuwiki headers reliably, since the page will be displaying in HTML — and to switch back and forth would be too verbose. So since we would be creating a new column layout in HTML anyway, with JavaScript to link and align the commentary, why bother using DokuWiki in the first place? Yes, it is convenient to have the project on the same Doku as the site, especially to track changes. But tracking changes can be done in other ways as well.

I would also state that recently the project has stalled because I started titling the sections for Rashi’s comments (which is a technical gaffe of DokuWiki — sections must have titles or they show up as blank in the TOC). In any normal reading case these comments don’t need to be titled, as they are essentially self-titled — but more importantly they are already linked to the verse.

Another solution would be to put the comments directly under the verses for which they appear, in collapsible frames. Perhaps under a clickable asterisk at the end of a line, or on a highlighted word. There is in fact a pop-up plugin (or, several) but I don’t really think a pop up would be ideal. I lean more towards the system on the truly excellent where the commentary can appear in a separate column when you click on the text.

So it seems the need for a custom web-app has finally reared it’s head. The only problem now is how to track changes made to the text, even if only to number them. But since these changes can amount to a simple diff between the KJV and what we have — more or less — it seems as if putting the text into a database is really the end solution here.

Dokuwiki was great for fleshing out the project, but with several major sections such as Notes, Cross-Reference, and Commentary, a more complex layout must be devised.

As an idea, in my mother’s RSV/NRSV there was a cross-reference near the center gutter of the text. In the Wesley Study Bible I use now, there is commentary in a section at the bottom of the page — as there is in the Stone Chumash. Also in the stone, Hebrew appears on the right side page while English appears on the left. This could be easily set-up, as well as having an interlinear version, with a proper mariadb CRUD application behind a web reader. It isn’t like I haven’t designed essentially the same thing before (ex. The ASR’s league pages).

The text would be interactive, controllable with mouse or keyboard. Clicking on a verse or moving to it would change the text in the commentary. Each chapter could be loaded in via JavaScript, which could maintain side-chapters for context and load more verses into browser memory as the user reads. Text is cheap, bandwidthically speaking, so this isn’t going to be a problem of data.

And when changes are made, the system could easily track those changes. It’s a good thing I didn’t scuttle the custom app I had already written. I will continue to design it from now, as a CRUD/admin section, and work on a reader later.

I didn’t expect it, but I’m going to have to write a full-fledged biblegateway or biblehub style system for this! It’s going to be exciting! So, this is why Hashem positioned me as a computer programmer with nothing to do! I have the perfect skill set and interest, uniquely, to embark upon such a project! Baruch Hashem!

One thought on “Doku’s Complex Document Problem

Leave a Reply

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