About hierarchies in WikiPageNames
Christian Boos
I've noticed some discussion about this topic, but I have the feeling
that it's not fully in sync with the latest developments and discussions
in tickets on t.e.o.
So here are a few informations that you might find useful.
Having a pseudo-hierarchy built from page names is a good thing, as it's
easily understandable by the users. It's also something that would
naturally translate to other kind of resources than the wiki (source
files of course, but also milestone names for submilestone).
But I agree that having a bit more support from the system would be
helpful. Currently, there's the TitleIndex macro, which can provide a
list of the subpages, but all of them instead of all the children pages.
This should eventually be addressed (the HierWikiPlugin has a
ChildrenPage macro or something similar).
Then, the semantic of relative links has changed in 0.11, as the
semantic used for 0.10, designed to match the one of URLs, was next to
useless. See r4442 for the changeset and
http://trac.edgewall.org/ticket/4411#comment:7 for a more detailed
discussion about the reasons for the change.
Relative links make now easy to write "relocatable" subsets of the Wiki,
by creating links to sibling pages (e.g. [../SiblingPage]), to parent
page (e.g. [.. the Parent]), to child pages (e.g. [./ChildPage]).
What's missing is an effective tool for doing this relocation. For that,
I've proposed a prototype UI for the Wiki Rename feature which would
allow multiple renames in one operation and that can be suited to move
whole hierarchies around, see
http://trac.edgewall.org/ticket/4412#comment:8.
-- Christian
Ilias Lazaridis
> Hello,
>
> I've noticed some discussion about this topic, but I have the feeling
> that it's not fully in sync with the latest developments and discussions
> in tickets on t.e.o.
>
> So here are a few informations that you might find useful.
(why don't you post directly within the topic?)
> Having a pseudo-hierarchy built from page names is a good thing, as it's
> easily understandable by the users.
It does not need many expertise to see:
Encoding multiple directory names directly into a filename is a 'bad'
thing.
> It's also something that would
> naturally translate to other kind of resources than the wiki (source
> files of course, but also milestone names for submilestone).
You should take the challange to implement a "folder" construct,
instead of encoding folder-information within the resource names.
> But I agree that having a bit more support from the system would be
... (plans interweaving several other constructs)
reading this elaborations of the responsible developer, I see that I've
choosen the right title:
WARNING - Encoding Hierarchy into the Wiki Name
http://groups.google.com/group/trac-dev/browse_frm/thread/2c613ff7b10859ff
If you keep and build uppon the current concept, you'll just ruine the
elegance of the wiki/trac implementation.
If you cannot resist, then _please_ keep this stuff in external
plugins, thus at least the trac core is not affected by this
'pseudo-hierarchy-design'.
.
Matt Good
> I've noticed some discussion about this topic, but I have the feeling
> that it's not fully in sync with the latest developments and discussions
> in tickets on t.e.o.
>
> So here are a few informations that you might find useful.
>
> Having a pseudo-hierarchy built from page names is a good thing, as it's
> easily understandable by the users. It's also something that would
> naturally translate to other kind of resources than the wiki (source
> files of course, but also milestone names for submilestone).
> What's missing is an effective tool for doing this relocation. For that,
> I've proposed a prototype UI for the Wiki Rename feature which would
> allow multiple renames in one operation and that can be suited to move
> whole hierarchies around, see
> http://trac.edgewall.org/ticket/4412#comment:8.
Yes, I think that for the moment we should stick to the current scheme
of using page names structured with "/" separators. As you've said you
can move a subset of the heirarchy by selecting all page names starting
with a prefix and replace that part of the name with the new
destination.
The suggestions of simply creating a "parent" field do not address the
fact that you could have the same name reused in different parts of the
Wiki. For example if you have a page located at "PageName/PageName"
you would create a naming conflict between the parent and child pages,
both named "PageName". Recreating the heirarchy also incurs the cost
of recursively looking up each parent, resulting in needing "n" queries
of the database to find the full path of a page "n" levels deep.
The current structure is not perfect, but it works OK for the current
database Wiki storage. The discussions of storing Wiki pages in under
Subversion (or other VC backend) have been revived and I think will be
a good time to explore the use of a more robust heirarchy. I think we
should wait to see what comes out of the VC storage efforts before
attempting to overhaul the database storage for Wiki pages.
-- Matt Good