Right now the ContentBase class is concrete. The first step would be to make it abstract and to introduce subclasses. Here are some of the kinds of subclasses that might be useful:
When setting up a federation, right now each content base is configured using:
<Namespace Root='file system path' Namespace='Some.Namespace' />
Once we introduce AbstractContentBases, you'd probably need to be able to specify the <Namespace> with differing kinds of Roots and Types. For example,
<Namespace Type='FileBacked' Root='file system path' Namespace='Some.Namespace' />
<Namespace Type='DatabaseBacked' ConnectString='some database connect string' Namespace='Some.Namespace' />
<Namespace Type='ProtocolBacked' Root='http://someotherserver/wiki.asmx' Namespace='Some.Namespace' />
etc.
I've been giving this a lot of thought and I think we really need to start the abstraction at the Federation Level. We need to provide a generalization of the Wiki Engine's Data Model. We also need seperate the Wiki UI engine into the base Rendering engine and the pages and controls that render the UI. More on this should be added under FlexWikiEngineDecoupling -- Hoop Somuah
Hmm. I don't know if I agree or disagree. What makes you think we'd need to introduce this abstraction with Federation. I worked pretty hard originally to keep storage issues confined to ContentBase. I happy to be shown that I'm wrong. Really... -- DavidOrnstein
One of the things that has occurred to me is the idea of a read-only ContentBase that, in essence, maps topics to something that generates content. For example, I might want MyBase.TopicOne and MyBase.TopicTwo to have TopicOne and TopicTwo to contain automatically generated content about two classes in an assembly (along the lines of some of the projects that use reflection to give Wiki documentation to classes). In this situation, you'd have a ReadOnlyContentBase that had some kind of hard-coded (in C#) behavior that governs what is displayed for each topic.
This is all a long-winded way to make a suggestion. If we decide to make ContentBase abstract, let's do the work to add one more layer in the class hierarchy that allows for a difference between read-only and read-write content bases.
For example (abstract classes in bold):
This would allow the UI code to be updated to, for example, hide things that are only meaningful for ReadWriteContentBases (like the Edit choice, the version history, etc.)
I'm starting to look in detail at what is needed to abstract away the link to the file store for ContentBase. The first thing I'm looking to accomplish is simply to refactor the code so that all the file system specific code is pulled out and the code that uses the results of, say, directory searches doesn't have these dependencies. This should lead towards a data provider model that was expecting to be linked to namespace as described above. I see no reason why including some kind of read-only indication in the provider couldn't be supported but I wonder if it wouldn't be wise to make that work first (since it doesn't affect the basic wiki semantics) before modifying the ContentBase to also support a different behaviour? -- AdrianBateman
One of the things to watch out for in the factoring is thinking about performance in various scenarios and with various kinds of backends. When I did the original design for ContentBase, I had in mind that the public face it exposes was probably the right set of functions that you might want to override for various different kinds of backends. If you just factor out all of the things that are currently done with file I/O into a different class and then build a hierarchy around that, we'd be unable to reimplement, for different kinds of backends, other functions that currently don't use file i/o directly but might still want to reimplement differently per-backend. Does that make any sense? -- DavidOrnstein
Yes, I think I understand. For example, we wouldn't want to break something out that resulted in multiple queries to a database where the same behaviour could be done with one query at a higher level. In the first instance, I'm not necessarily thinking about breaking everything out into another class (though a helper class might help to simply draw things together), just using Extract Method to pull out the file system operations. I think this will make the storage mechanism more obvious and allow clearer thinking about the abstraction including the ideas you have above before making any firm decisions. Does this sound like a sensible approach? -- AdrianBateman
Yes. -- DavidOrnstein
Would anyone else find a VSS-backed content base useful, or maybe even one using the MS Source Code Control Provider API if we're going to be a bit more generic? As I already manage a lot of "content" in the form of source code, so if I could store the wiki text in the same place it would make my life somewhat easier -- Paul Bartlett
I find version control system backend very useful. I see lots of benefits:
Subversion http://subversion.tigris.org/ could be a good choice: it is freeware, it has very good set of features (atomic commits; file name and directory renames versioned etc) and it has programming API. And it is relieable. -- TanelHiir