TWiki like configuration

[anonymous]

I would like to see in Trac a ​Twiki like configuration support. TWiki uses special statements inside wiki pages for all configuration. I think it could easy administration steps a improve modularity.

TKS

[Christopher Lenz]

Doing configuration in wiki text is a pretty lame user interface IMHO. Wiki text is about formatting/structuring content.

Anyhow, you'll need to be more specific about what kind of configuration you'd like to do on wiki pages. Feel free to reopen this ticket if you have a concrete proposal.

[Christian Boos]

I'm not so radical on this, as I believe that configuration and content are sometimes close.

For example, the InterWiki feature monitors a special page (the InterMapTxt page) to manage the list of InterWiki prefixes and their corresponding targets.

Another example would be content fragments which could be inserted in predefined places in the Trac interface.

To be specific, the ticket #2021 could be reimplemented by using the content of TracTickets/NewTicketPolicy wiki page instead of a content generated using the site_newticket_policy.cs template, as currently proposed.

[Christopher Lenz]

InterWiki is a good example, the ticket policy is not. As I think I've stated before, making the ticket policy text a wiki page (or fragment thereof) would make the ticket system depend on the wiki page system. While any Trac component/plugin/subsystem can expect the wiki formatting to always be available, the wiki page subsystem can be disabled.

However, this ticket is about doing all configuration in wiki pages. This isn't going to work for Trac, where the wiki is merely an optional subsystem.

[rfonseca@…]

OK, I agree. The fact of wiki being merely an optional module can block this issue. My proposal about wiki like configs is regarding flexbility and modularity. This way, one could create a database over wiki data.

An example from TWiki is the user groups being a wiki paged named as <AnyThing>Group. Any plugin would be able to read directly from it and no SQL databes would be needed.

[Matthew Good]

Well, this issue is already closed, but since there are still a few points up in the air I'll make a few comments.

1. The WebAdmin plugin already provides a way to configure many of the project settings online. Some of these pages provide a much better interface to configure the settings than a Wiki page would offer (probably most notable is the plugin configuration).
2. A SQL database is not a bad thing. It provides a way to structure the data, which makes it easier to prevent against invalid configurations than the free-form data of a Wiki field.
3. Most plugins should not need to go directly to the database since there are appropriate APIs for things like checking a user's permissions, or reading from the configuration. Portions of the API may need filled out more, but it should easier for a plugin than parsing out options from a Wiki page.