Flex Wiki Engine Decoupling

Summary

This topic concerns decoupling the FlexWiki Engine from it's UI and it's back end storage to allow extensibility in those areas

At first glance these suggestions may seem complex but this is very much like the current implementation of FlexWiki. These suggesteions merely move things around to allow people to cutstomize FlexWiki in their own ways without preventing them from contributing to the core of FlexWiki. However the changes suggested by this topic would probably involve significant enough changes to the source to merit a significant verion number change.

Check out the ThreeWikiFormats topic which relates to this content.

ToDo

Where do behaviors fit in here? Maybe we need an entry in the config to allow adding of new behaviors?

There are 3 2 parts of FlexWiki that should be decoupled from the current engine to make it a more flexible solution.

DavidOrnstein

You say 3 but I only see 2.

HoopSomuah

I was thinking of adding a section about extensibility but I'm not sure about it so for now I'll say 2

Data Model - An abstract data model would allow wiki content to be stored in a variety of sources. It would also pave the way toward a SOAP interface to FlexWiki which would in turn help with LinkedFederations. (Note that OmarShahine is working on the FlexWikiWebService that may help with this also...)
Rendering Engine - Seperating the current UI from the core wiki rendering logic would allow people to implement their own UI and still be able to upgrade their rendering engine when updates are made to flexwiki.

Data Model

Currently the data structures that are needed for generalization are:

Wiki Federation (FederationConfiguration and Federation)
Wiki Base (ContentBase)
Wiki Topic (a specific class doesn't Exist in current FlexWiki)

I suggest we define the following interfaces:

IWikiFederation

string Name { get; set; }
IEnumerable LinkedFederations { get; set; }
IEnumerableWikiBases { get; set;}

IWikiBase

ITopic FindTopic(TopicName topic)
IEnumerableGetTopics(bool includeImports, bool includeDeleted)
void DeleteTopic(TopicName)
TopicExists(TopicName topicName)

IWikiTopic

CreationTime
TopicChanges[] History{ get; }
void Rename(string newName)
void Change(TextReader editedTopic)

Note

The above lists are not yet complete, please add as appropriate. Also the exclusion of a public method, or property from one of the above listings may be either because It has been inadvertently overlooked (in which case you should add it) or because it is considered implementation specific (dealing with file paths etc.) and shouldn't be in the data interface. Also ,I see the above as being interfaces because I can't think of very much implementation that they need to share

DavidOrnstein

I think adding a topic class or interface is a good idea generally.

DavidOrnstein

You should look closely at the implementations of the current Federation and ContentBase classes; there are a lot of public methods there -- I think the above list is probably way too short [which you acknowledge; I'm just agreeing].

DavidOrnstein

I've got mixed feelings about the interface versus class question. I actually suspect that, for example, a set of subclasses that represent ContentBases will, in fact, want a bunch of shared implementation. On the other hand, that doesn't mean we wouldn't want to have an interface, too -- looser coupling. What about the fact that interfaces doesn't version as well in .NET?

HoopSomuah

Interfaces definitely have versioning problems and I agree that as we expand the members of the proposed types if we come up with functionality that might be shared we should switch to abstract classes instead. All-in-all using abstract classes isn't such a bad idea but I do think that Interfaces would be more ideal. Why can't we fix the versioning problem in .NET?

JeffGonzalez

What versioning problems are you talking about? I have always understood composition (interfaces) to be superior to generalization (inheritance), when it comes to versioning. Are you talking about the naming standards(IInterface, IInterface2, IInterface3, etc...)?

Then the default FlexWiki data providers would consist of

XmlFederationStore : IFederation - This would use the configuration information as described in AbstractContentBase which would probably be just an extension of our current FederationConfiguration and Federations classes.
FileBackedContentBase : IContentBase - Basicaly the current ContentBase class
File Based Wiki Topic class : IWikiTopic

Note

The configuration specifics of an IWikiFederation implementation should be handled seperately from the base FlexWiki configuration described below

Rendering Engine

The Rendering Engine would consist of:

FlexWiki.Web.dll - Assembly containing the compiled UI elements for basic FlexWiki rendering
Web.Config Config Section Handler

DavidOrnstein

We should be careful here about too much coupling to the web.config file. I say that because I think that we're talking here about (among other things) being able to have different rendering machinery -- and some of those we'll want to work without the web (e.g., pure client-side).

HoopSomuah

I agree but since ConfigSection handlers work for any .NET app the only thing we would nee to do would be to seperate the rendering config section from the Data engine config section. Someone implementing a pure client-side system or an Avalon-interface could use a diffrent system.

FlexWiki.Web.dll

FlexWikiHttpHandler : System.Web.IHttpHandlerFactory - Registered in Web.Config (or Machine.Config) as an http handler that deals with paths that end in .wiki
FlexWiki.Web.Page : System.Web.UI.Page - Base class for rendering wiki pages
""FlexWiki.Formatting" - Contains Types used for formatting and rendering Wiki content.

Web.Config

FlexWikiConfigSectionHandler - Section of Web Config devoted to Flex Wiki Engine configuration

Federation - Config Entry that registers IWikiFederation implementations with http paths. (the FlexWikiHttpHandler will use these entries to figure out which IFederation gets associated with a specific request eg. <Federation path="/MyFederation" type="CustomCode.SQLFederation" />
WikiPage - This entry identifies the page class used for rendering contentthis must be either an aspx page of a class that inherits from FlexWiki.Web.Page The handler will pass processing of an httprequest to this page after the appropriate Federation and Namespace have been loaded. eg. <WikiPage page="wikipage.ascx" /> or <WikiPage page="FlexWiki.Web.UI.WikiPage" />
Emoticons - Section similar to the transform section used in ASP.NET Forums that contains emoticon mapping information eg. <Emoticon string="" image="./images/smile.gif" />

The Current FlexWiki UI would sit on top of this rendering engine and consist of:

FlexWiki.Web.UI.dll : FlexWiki.Web.Page The default FlexWiki Page implementations would live here. People wanting to implement their own UI would not need this dll.
\images\ - Folder containing all the images used by this UI

	Show Changes
	Edit
	Print
	Recent Changes
	Subscriptions
	Lost and Found
	Find References
	Rename
	Administration Page