Scratchpad for 'Tavi design ideas. See also TaviToDo, TaviSuggestions.

Note that much of the following discussion has been superseded by the fact that 0.20 is now out the door. :-) It is retained for whatever educational or informational purpose it may serve.

Problem

The code as currently written is monolithic, not easily extensible, and tightly couples content and form.

Point

It's a wiki; it should embody Wiki:WorseIsBetter?. Simplicity should come before extensibility.

Counterpoint

Simplicity should always come first. Some form of modularity is needed for some of the ideas we'd like to implement. And there's no way to avoid the need for decoupling content and form. See SquirrelMail:SquirrelMail for examples of some of the interface changes I'd like to make much easier.

Meta

If we're gonna do any sort of restructuring, we might reconsider the question of language. Now that I (Scott) am familiar with Perl's DBI, the "need" to use PHP is gone. And with Perl we might even avoid the regex hoops that PHP makes us jump through. Just a thought. I know Paul won't like that. ;-)

Proposal

Have a text parser and have a renderer. Keep them separate. The renderer should expose a set of functions (either use classes or callbacks) to render certain objects (character, line, WikiName, category list, etc.). The parser feeds the renderer a stream containing these objects.

Benefits

The parser can be inserted in-place wherever it is needed. It could be used in something like, say, MeatBall:WikiLog? without any significant tweaking.

We might provide a means for users to implement their own parsers. I'm not sure whether this would plug directly into our parser, sit in the stream between our parser and the renderer, or sit in the stream behind our parser. MoinMoin does this, and it's fairly cool. How much need is there for this, though? Especially if a wiki engine out there already does it?

Thought

What if this stream were XML? It'll cost us, though, to convert the text into XML and then transform it to HTML. Grr. Probably better stick with the "yo, function whatzit, here's a WikiName; do what you want with it" approach.

However, what if it were stored in XML? Parsing then happens at save-time, and rendering happens at load-time. Might have some serious merits. . . . Except that we have to "un-parse" when it comes time to edit or do a diff. :-( Or else store both source and XML forms (and pre-rendered cache? ;-). (On the plus side, PHP has XML support built in. Do most ISP's compile PHP with XML support turned on?)

Question

How do we implement this such that it allows us to easily add things like UseMod:FreeLinks?. Maybe we have a dozen parsers, each implementing a single markup element (e.g., WikiNames, ordered lists, italics, etc.). Then there's a master configurator thingy that wires them together in the proper order.

Concerns

Is this overkill? See comments on UseMod:UseModWiki/WhyAnotherWiki? for why this might be true. If anything, maybe I should be looking to trim the code. Then again, there is the ever-present need to separate form from content.

XML, XSLT

Whoa. XSLT is wicked cool. If we store our markup in some sort of Wiki XML, then we might be able to seamlessly use XSLT to morph it into proper HTML. See [1], [2]. Nifty.

Alas, Sablotron isn't built into he.net's PHP. And it probably isn't all that common on the web.

XML and XSLT

This is what I am looking for in a Wiki... unfortunately the only one I can find currently runs on ASP. grrr... I think... storing to XML flat file on the system with no db... is the stuff man. then xslt transform on view. hot stuff.