WARNING - Encoding Hierarchy into the Wiki Name
Ilias Lazaridis
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).
.
Luis Matos
I have to support this:
imagine a complex wiki page with lots of attachments and ... you
misspelled its name.
i've done this (and it was pretty hard to do all again). I've uploaded
more than 1Gb of videos and photos with descriptions from a techology
fair called EMAF but i created the page like EMEF ... well ... lots of
time that went to space :P
--
Best Regards,
--
Luis Matos
Noah Kantrowitz
* WikiRename
* HierWiki
The first lets you move pages, the second has a module to enforce
correct hierarchy creation.
--Noah
Ilias Lazaridis
Noah Kantrowitz wrote:
> Two plugins to look at
> * WikiRename
> * HierWiki
>
> The first lets you move pages, the second has a module to enforce
> correct hierarchy creation.
A workaround on top of a workaround.
Then another workaround is placed on top of those.
Then trac becomes unmanagable.
The main point is:
> > 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).
-
http://dev.lazaridis.com/base/ticket/2
.
Jani Tiainen
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
Ilias Lazaridis
Ο/Η 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.
.
Doug Douglass
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
Jani Tiainen
Doug Douglass wrote:
> 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?
After good night sleep I think I got hang of it what mr Lazardis tried
to say.
Basically there is only need to have unique identifier for each page,
preferably something autogenerated (like a number). Currently there is
none.
So you could always point to absolute page just by having it's number
(like permalinks in many blog/news systems). So in theory you could
have "http://trac.foobar.invalid/wiki?page=123" that points to absolute
page. Then you can name your pages (that is separate to identifier) as
you wish.
Then add new property, parent that would be like foreign key to some
unique id and you're done.
This way managing hierarchies (in point of user) would be simple.
Only problems will arise when you start to refer absolute pages from
other pages. How you refer to them? By using absolute page number?
Writing expanded path that engine would encode *before* saving to
absolute number. Write it as it is now and wish that no-one does
reparenting?
Can two pages under same parent have same name or do they need to be
unique in that context?
--
Jani Tiainen
Ilias Lazaridis
> Doug Douglass wrote:
> > 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?
>
> After good night sleep I think I got hang of it what mr Lazardis tried
> to say.
>
> Basically there is only need to have unique identifier for each page,
> preferably something autogenerated (like a number). Currently there is
> none.
>
> So you could always point to absolute page just by having it's number
> (like permalinks in many blog/news systems). So in theory you could
> have "http://trac.foobar.invalid/wiki?page=123" that points to absolute
> page. Then you can name your pages (that is separate to identifier) as
> you wish.
>
> Then add new property, parent that would be like foreign key to some
> unique id and you're done.
>
> This way managing hierarchies (in point of user) would be simple.
This sounds good, but such a change would be difficult to implement
backwards-compatible.
My suggestion takes the existent status of trac in account.
I really meant to:
* use the page name as is (CameCase or wiki:pagename)
then:
* add a field parent
* make this field editable in the wiki-edit mask (for reparenting)
* provide a tiny function to create the "parent-tree"
at a later point:
* provide a function which generates a full menu-tree.
All this is implementable without major effort.
It leaves the "HierarchicalWikiPagesWith/Slash" fully intact (for those
which like to use them).
Ilias Lazaridis
Doug Douglass wrote:
> Just a few comments...from a users perspective...
>
> I don't believe that separation of pagename from hierarchy is as simple as
> you suggest.
It's really that simple (seen it in another wiki, don't remember where.
worked very simple and intuitive).
> 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?
Yes.
It remains a wiki - not a CMS.
(but this limitation could be overcome somehow to a later point).
> 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.
No, It gives you the ability to define a complex hierarchy (from which
e.g. a navigation-bar can be derived).
> FYI, I used TWiki (circa version 4) for years before coming to Trac. TWiki
...
> 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.
The suggested "parent" system is very simple, simpler that TWiki and
Tracs actual "encoded Hierarchy".
John Hampton
> * add a field parent
> * make this field editable in the wiki-edit mask (for reparenting)
> * provide a tiny function to create the "parent-tree"
What happens when you create a wiki page: Level1/level2/level3/PageName
Especially if level2 and level3 are actually pages in their own right.
How do you recreate the hierarchy then? Do you create dummy page
entries for level2 and level3 that have corresponding parents? Is the
parent simply the whole path (Level1/level2/level3)?
While I admit that there should be some core functions for allowing the
page name and hierarchies to be changed, I don't see how adding a simple
"parent" field will actually simplify the situation. Especially when
talking about "backwards compatibility".
-John
Jeroen Ruigrok/asmodai
>* use the page name as is (CameCase or wiki:pagename)
[snip]
>* add a field parent
[snip]
>It leaves the "HierarchicalWikiPagesWith/Slash" fully intact (for those
>which like to use them).
A horrible kludge in my opinion since you are effectively duplicating
hierarchical logic on two levels now. That way be dragons.
--
Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai
イェルーン ラウフロック ヴァン デル ウェルヴェン
http://www.in-nomine.org/
Seize from every moment its unique novelty and do not prepare your joys...
Ilias Lazaridis
John Hampton wrote:
> Ilias Lazaridis wrote:
> > * add a field parent
> > * make this field editable in the wiki-edit mask (for reparenting)
> > * provide a tiny function to create the "parent-tree"
>
> What happens when you create a wiki page: Level1/level2/level3/PageName
>
> Especially if level2 and level3 are actually pages in their own right.
> How do you recreate the hierarchy then? Do you create dummy page
> entries for level2 and level3 that have corresponding parents? Is the
> parent simply the whole path (Level1/level2/level3)?
You would simply create page "Level1".
Then Level2 (assigning parent "Level1", or autoassigned, when created
from within Level1)
Then Level3 (assigning Level2)
Then PageName (assigning Level3)
If you hit o "PageName", the hierachy is displayed within an navigation
bar (e.g. left-sided from wiki-context-nav):
Start -> Level1 -> Level2 -> Level3 -> PageName
If you edit "PageName" parent field and set it to "Level2", the
navigation bar displays
Start -> Level1 -> Level2 -> PageName
The url displays always: trac.domain.org/wiki/PageName
Ilias Lazaridis
> -On [20061220 19:55], Ilias Lazaridis (il...@lazaridis.com) wrote:
> >* use the page name as is (CameCase or wiki:pagename)
>
> [snip]
>
> >* add a field parent
>
> [snip]
>
> >It leaves the "HierarchicalWikiPagesWith/Slash" fully intact (for those
> >which like to use them).
>
> A horrible kludge in my opinion since you are effectively duplicating
> hierarchical logic on two levels now. That way be dragons.
Trac Core does not have hierachical wiki-names.
If one uses the "hardcoded" wiki-names (based on the add-on plugins),
he can either migrate - or choose to use them further.
.
John Hampton
> You would simply create page "Level1".
>
> Then Level2 (assigning parent "Level1", or autoassigned, when created
> from within Level1)
>
> Then Level3 (assigning Level2)
>
> Then PageName (assigning Level3)
I hope you suggesting that these pages are autocreated when I create a
page /Level1/level2/level3/PageName.
If you are, then I hope you realize that this change is slightly more
than simply adding a "parent" field
If you aren't, then I consider this a HUGE loss of functionality. It is
nice to be able to enter any arbitrary hierarchy and create a page
without requiring that the "parents" exist.
> The url displays always: trac.domain.org/wiki/PageName
Thus effectively rendering the need or desire for a hierarchy in the
first place. It also makes it such that no two pages, regardless of
hierarchy, can have the same name.
All in all, I don't see what is horribly wrong with the current scheme,
and I definitely think your proposal is a step in the wrong direction.
-John
Jeroen Ruigrok/asmodai
>Then Level2 (assigning parent "Level1", or autoassigned, when created
>from within Level1)
>
>Then Level3 (assigning Level2)
>
>Then PageName (assigning Level3)
>
>If you hit o "PageName", the hierachy is displayed within an navigation
>bar (e.g. left-sided from wiki-context-nav):
>
>Start -> Level1 -> Level2 -> Level3 -> PageName
>
>If you edit "PageName" parent field and set it to "Level2", the
>navigation bar displays
>
>Start -> Level1 -> Level2 -> PageName
>
>The url displays always: trac.domain.org/wiki/PageName
Then the solution seems even more flawed since it cannot allow a construction
such as:
Level1/PageName
Level2/PageName
Jeroen Ruigrok/asmodai
>Trac Core does not have hierachical wiki-names.
I am aware of that, however you are stuck with your mind in the technical
stuff. I was talking about user added logic such as calling the page
Blah/PageName in the first place.
Adding another hierarchical level by adding the parent field will only add
complexity and confusion.
Either go one way or another, but not some flawed way due to preserving
backwards compatibility or due to not thinking out the concept well enough.
Ilias Lazaridis
John Hampton wrote:
> Ilias Lazaridis wrote:
> > You would simply create page "Level1".
> >
> > Then Level2 (assigning parent "Level1", or autoassigned, when created
> > from within Level1)
> >
> > Then Level3 (assigning Level2)
> >
> > Then PageName (assigning Level3)
>
> I hope you suggesting that these pages are autocreated when I create a
> page /Level1/level2/level3/PageName.
of course not (like on any filesystem).
> If you are, then I hope you realize that this change is slightly more
> than simply adding a "parent" field
>
> If you aren't, then I consider this a HUGE loss of functionality. It is
> nice to be able to enter any arbitrary hierarchy and create a page
> without requiring that the "parents" exist.
>
> > The url displays always: trac.domain.org/wiki/PageName
>
> Thus effectively rendering the need or desire for a hierarchy in the
> first place. It also makes it such that no two pages, regardless of
> hierarchy, can have the same name.
You are still free to add a standard suffix (like it's with the current
pseudo-hierarchy functionality, just without a slash.)
> All in all, I don't see what is horribly wrong with the current scheme,
> and I definitely think your proposal is a step in the wrong direction.
No.
It's just the 1st step towards the direction of a standard file-system
functionality.
.
Ilias Lazaridis
Jeroen Ruigrok/asmodai wrote:
> -On [20061220 21:51], Ilias Lazaridis (il...@lazaridis.com) wrote:
> >Then Level2 (assigning parent "Level1", or autoassigned, when created
> >from within Level1)
> >
> >Then Level3 (assigning Level2)
> >
> >Then PageName (assigning Level3)
> >
> >If you hit o "PageName", the hierachy is displayed within an navigation
> >bar (e.g. left-sided from wiki-context-nav):
> >
> >Start -> Level1 -> Level2 -> Level3 -> PageName
> >
> >If you edit "PageName" parent field and set it to "Level2", the
> >navigation bar displays
> >
> >Start -> Level1 -> Level2 -> PageName
> >
> >The url displays always: trac.domain.org/wiki/PageName
>
> Then the solution seems even more flawed since it cannot allow a construction
> such as:
>
> Level1/PageName
> Level2/PageName
this would be the next (development) challenge to take (e.g. automated
display of a list with both pages, or another construct).
.
Ilias Lazaridis
> -On [20061220 21:57], Ilias Lazaridis (il...@lazaridis.com) wrote:
> >Trac Core does not have hierachical wiki-names.
>
> I am aware of that, however you are stuck with your mind in the technical
> stuff.
My requirements result out of a practical use-case.
> I was talking about user added logic such as calling the page
> Blah/PageName in the first place.
that's ok.
No need to use the parent field (e.g. can enable another plugin to
display the hierarchy).
> Adding another hierarchical level by adding the parent field will only add
> complexity and confusion.
Wait a little to see the upcoming complexity an the confusion if trac
continues with its current "pseudo-hierarchy".
> Either go one way or another, but not some flawed way due to preserving
> backwards compatibility or due to not thinking out the concept well enough.
You are not obligued to use the one or the other concept.
.
Ilias Lazaridis
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
See comment of related trac developer:
About hierarchies in WikiPageNames
http://groups.google.com/group/trac-dev/browse_frm/thread/18b933cbdb4704f1/#