Active development of JAMWiki has ceased, and bug fixes and support will be limited at best. If you are interested in taking over management of JAMWiki please send an email to the jamwiki-devel mailing list.


ktip.png This page (and all pages in the Tech: namespace) is a developer discussion about a feature that is either proposed for inclusion in JAMWiki or one that has already been implemented. This page is NOT documentation of JAMWiki functionality - for a list of documentation, see Category:JAMWiki.
Status of this feature: NOT IMPLEMENTED. As of JAMWiki 1.1 this functionality is probably better implemented with a custom JFlex parser tag.


The intention of this enhancment is to create a new magic word which allows to display a trail of links which the user followed to reach the current page. It allows the user to go back to pages not only by hitting the browser back button but also by choosing a page which lies on higher hierarchy levels.

I created the following two magic words:


This displays the first trail which can be found. As I have found out this trail can be rather long. E.g. if this magic word is used in a Template then the template can show up in the link trail. As the template is used by many pages a long link trail can result (unfortunately I was not able to tell the SearchEngine not to investigate the links which are caused by my link trail. This would be much easier: Is it possible to create links which are not considered by the SearchEngine?).

Therefore I also created:


C stands for complete and checks all possible link trails in order to find the shortest one (which is the one making the most sense, in my opinion). It works quite well but I am afraid that a performance issue is likely to arise if the wiki contains many pages linking to each other.

This is what it looks like:


How it works[edit]

First the default topic for the current wiki is determined. Whenever the recursive search reaches this topic it stops and returns the trail which is found so far. This is what happens when BACKLINKLIST or BACKLINKLISTC is called for topicName:

  • get all pages (preTopics) which link to topicName
  • take the first result (in case of BACKLINKLIST) or take all results (in case of BACKLINKLISTC) and call the recursive method again for each result
  • stop if the wiki's default topic or an already visited page is reached
  • in case of BACKLINKLISTC: return the shortest of all found trails

Changes Made to JAMWiki[edit]

    • added new constants for magic words
    • added methods for accessing search engine

Wish List[edit]

  • can links be made invisible for the SearchEngine?


An example image of a link trail:




Changes can be found in my personal branch:

  • first version implemented in


Possible Problems / Questions[edit]

  • in large heavily interlinked wikis the recursive search might take a long time. Perhaps a maxDepth should be introduced to stop the search early enough
  • is it ok to embed the code in Unlike the other magic words it takes more than one or two lines of code in method processMagicWord, so perhaps it should be sourced out into a separate class. Maybe a kind of plug-in mechanism would be reasonable which allows to register new MagicWord-Classes to

User:DiegoB 15-Aug-2007 03:24 PDT

A lot of tools simply add an object to the user session that keeps track of the path the user has followed - that approach might address any performance issues. I haven't had a chance to look at your code yet but will try to do so soon. -- Ryan 15-Aug-2007 21:07 PDT
That might be a solution. But there is one drawback: If a user enters a page through a search the session object procedure would display something like "SearchResults > FoundPage". This is correct in a sense of "path the user followed" but it does not reflect the navigational structure in wich the page is listed. User:DiegoB 15-Aug-2007 23:13 PDT
I've had a chance to look at the code and to ready through the comments in this article, and one major concern I have is that wikis are by design generally not hierarchical - any given page may have literally hundreds of paths by which it could be reached from the root page, or alternatively there may be no way to reach the root page from a topic. Another concern is that using the "links to" functionality has performance implications, so on a large wiki that could potentially be a problem.
I like the idea of trying to show where a page lies in the hierarchy, but I'm not convinced that it's something that could work consistently on a wiki. I'd be interested in hearing further comments from you and others about what the use-cases for this functionality would be and whether there might be a better way to meet those use-cases. As a side note, almost since day one I've wanted to have a way for users to create their own tags, and functionality like your backlink implementation might be a good candidate - provided a structure was put in place you should be able to easily add this functionality on your own site, and others who were interested could then download a plugin to implement it for themselves. If that's something people want then I'd definitely be interested in getting a discussion going about how it could be implemented for an upcoming release. -- Ryan 16-Aug-2007 20:33 PDT
I would prefer this plugin solution. I see that my solution might cause performance problems so in my opinion it would be better if the backlinks were no integral part of JAMWiki but an additional plugin. Concerning the use cases: We want to build up a kind of knowledge base (mainly software development topics). There will be some main pages like "Development", "Application Support" and so on. All other topics will be placed on these base pages. So in this special wiki there will be a hierarchical structure and from my point of view it is very helpful if you can see directly where you are. Another use case is the wiki you already mentioned: There is always the possibility to go back to a "broader" information level and to drill down to new information from there. User:DiegoB 17-Aug-2007 05:59 PDT