> Another alternative I was thinking about, was to move the settings > into their own dll. That would give a higher degree of separation from > the web app add maybe get us towards where Craig wants to go by having > the settings editable within the wiki while at the same time meeting > David's requirement not to lock the wiki into a web app only format.
Two things. First, putting words in David's mouth, I believe his concern is not to lock us into HTML-only. We're already at not-web-app-only if you consider things like the web service. Second, I'll articulate my (admittedly half-baked) vision of where wiki configuration should go. I think that there should be a special "meta namespace" that represents the wiki itself. Maybe something like "FlexWikiConfig" by default, although we could allow for it to be changed, perhaps via the only setting we allow in web.config. In the meta namespace, there would be topics that correspond to the sections of the flexwiki.config file. So there might be a topic called WikiAuthorization that looks like this: AllowRead: all AllowEdit: authenticated That would set the defaults for the whole wiki. Similarly, there might be a topic called NewsletterConfiguration that had properties like this: Enabled: true SendAsAttachments: false Or a topic called WikiNamespaces like this: Namespaces: FooNamespace, BarNamespace Which would reference topics called FooNamespace and BarNamespace, which might look like this: Name: NamespaceOne Provider: FlexWiki.FileSystemNamespaceProvider Root: Namespace\NamespaceOne Etc. etc. The main advantages I see to this system are: * It makes the wiki consistent - you edit wiki configuration the same way you edit namespace configuration. Why should we need to write XML *and* WikiText? * You can just unzip the distribution and fire up the app. * You can store your wiki configuration in SQL Server. If the caching ever gets smart enough to deal with web farms (wasn't in 1.8, still isn't in 2.0, although I can see how to make it so), then this will allow true scale-out. * It can be self-documenting by virtue of having comments right in the configuration pages. * It works really well with the templating stuff that Derek (it was Derek, right?) added. All this said, I think we should try to figure out how this story fits in with the /admin app. That is, although this would give us a nice "command-line" style administrative interface (always a good thing) we need to keep in mind that the "GUI" stuff is important, too. We already have the ability built-in to read and write properties, so I don't think that's going to be hard to figure out, but it should be remembered. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Flexwiki-users mailing list Flexwiki-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flexwiki-users
