I figured it might not be a bad idea to send out a progress report every Friday. So if you don't see one, ping me and remind me.

If you don't want to read low-level technical details about how FlexWiki is implemented, you can delete this message now.

I'm actually making pretty good progress on the refactoring. Things seem to have stabilized in terms of wholesale reorganization of the code. I have refined the model somewhat, though: rather than making every single class that provides content (e.g. the security filter, the caching layer, the filesystem store itself) implement IContentProvider, I've split the providers into two camps: those that implement IContentProvider, and those that implement IContentStore. They're arranged in a chain with ContentManager at one end and a single implementation of IContentStore at the other end. In between sit the filters, which extend IContentProvider. So an example stack looks like this:

ContentManager for some namespace

• Security provider - implements IcontentProvider
• Caching provider - implements IcontentProvider
• Parsing provider - implements IcontentProvider
• File system store - implements IcontentStore

IContentProvider extends IContentStore, so every operation on a content store can be (and is) intercepted by all the filters.

You'll note also the introduction of the parsing provider. As I was working my way through the IContentProvider interface, I discovered that FlexWiki was really treating content in two ways:

• As a pile of text
• As an ordered collection of abstract tokens (e.g. WikiWords or properties)

Two things about this gave me some trouble. First, it meant that every content store has to be aware of how a topic is parsed. Second, it was weird that there were two representations of the same thing all the way through the pipeline. I couldn't really get around the second one - that's just how FlexWiki works. I could have solved the second on by creating a ContentStoreBase base class that all content stores have to derive from, but I dislike inheritance in general, and it seemed better to leverage the lovely pipeline architecture that we're going to have anyway.

I like this new breakdown because it may make it possible for certain providers to inject content into the abstract parse tree directly, rather than having to futz with the unparsed wiki text. Also, it should make the Formatter much simpler, since it will have access to the parsed form of the wiki text. But that's a future enhancement: doing a full parse is out of scope for my efforts at this stage - I'm just pulling out the bits I need and hoping to get it reasonably close to something more general purpose.

I can't tell you how long it's going to take to finish, but progress has been steady. I have about 15 unit tests complete and working against ContentManager, where I'll probably need to have something like 150 by the time I'm done with the skeleton implementation. So, not bad.