Ilias Lazaridis wrote: > Trac works nice, but has several deficits. > > One of the deficits are the missing possibility to apply a hierarchy to > the wiki documents. > > I've noticed that the trac-team uses a construct, which can best be > rated as a "temporary workaround". > > ProjectPlans/DoingThis > > here, the hierarchy-information is 'hardcoded' into the wiki-page-name, > which makes "the change of hierarchy" very difficult. > > A main benefit of wiki's is lost: > > The ability to create documents on-the-fly, whilst applying (or > changing) hierarchy to a later point. > > The trac team should not use this workaround further, but instead > provide a _real_ hierarchy for the wiki (it's just a field "parent" > within the wiki model).
Main benefit of wiki is to provide simple, collaborative, fast way to publish documents on web. And that is achieved with simple markups. Trac uses MoinMoin-style of links, that means using CamelCase and "hardcoding" paths. And MoinMoin has large userbase so I don't think that it's not considered as a workaround. I would rather prefer MediaWiki style http://www.mediawiki.org/wiki/Help:Links it's bit more flexible with naming pages but that's just a matter of taste. Problem that lies here is not how hierarchy is represented - it's just that there is not really built-in (core) tools to change either name nor hierarchy of pages that creates feeling that these external tools are "hacks". Even you introduce some other "hierarchical" way to represent documents, you still need tools to manage and modify hierarchy. ... just my 0.02€ -- Jani Tiainen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
