Just a few comments...from a users perspective... I don't believe that separation of pagename from hierarchy is as simple as you suggest. And, IMHO I don't think the two should be functionally separated.
In the simple case you describe of a field that is the name of the "parent" page, with no changes to the page reference syntax ( i.e., CamelCase), all pages would still need to have unique pagenames, would they not? I think what you are describing is more page lineage (i.e., what page created me, what pages were created from me) then organizational hierarchy. FYI, I used TWiki (circa version 4) for years before coming to Trac. TWiki has a built-in single hierarchy called a Web, that contains Topics (i.e., wiki pages). The page reference syntax had direct support for this single hierarchy, defaulting to the "current" Web if a Web is not explicitly provided. There is also a function for moving pages between webs that updated all pages that reference the moving page. Of course, users always wanted the ability to nest Webs within Webs. TWiki also has built-in support for parent-child lineage, which, again, I think is a more accurate feature description than what you have described as hierarchy. Coming from this TWiki background, I like the simplicity within Trac of just naming the topic to appear as if it were in a hierarchy. Add in a plugin to parse these hierarchical names and you have a nice, simple solution. Yes, there are downsides. Regards, Doug On 12/19/06, Ilias Lazaridis <[EMAIL PROTECTED]> wrote: > > > > Ο/Η Jani Tiainen έγραψε: > > 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. > > It seems it is, at least as long as it's usage is not optional (e.g. no > other way to provide a hierarchy) > > > 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. > > It's just one field, "parent". > > when a page is first created from within another wiki page is populated > automaticly with the parents wiki name. > > a simple "reparent" function (e.g.: a simple editable field) to enable > to se another parent. > > and finally, an navigation-bar which displays the hierarchy (by simply > reading the parent fields recursively). > > Pagename and hierarchy are this way fully independent. > > . > > -- > http://dev.lazaridis.com/base > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
