There are a variety of places that a WiKi's nodes-and-links-without-text data could come in handy:

• for Touch Graph wiki browser: currently have script which dumps results to a page which I copy/paste into a text file

• other global/batch Graph Drawing apps

  • eventual Idea Graph support

• local (around current page) Graph Drawing apps

  • Visual Tour: note that WikiWikiWeb:VisualTour doesn't include all nodes in its drawing, it uses some rules to try and thin out the herd

• Visible Backlinks: cached Back Links to show in each page, because (a) most people never think to hit that button, and (b) when they do the performance isn't great

• maybe some WikiWeb/Sister Sites browser?

ZWiki stores the forward links in each pages properties: as links and canonicalLinks

• in both cases they include valid (pattern-matching) Wiki Word-s, even if there is no page with that [ID].

• for me these seem mostly the same - that may be less the case when there's a Zwiki Tracker involved

• in canonicalLinks the colon gets removed from the middle of a Remote Wiki U R L

• in some pages I've seen some non-Wiki Word [URLs] or odd pieces of [URLs] in links which I haven't seen in canonicalLinks - but on other pages I haven't seen such stuff.

Argh, neither property is a unique list --Bill Seitz, 2003/07/21 17:20 [GMT]
So I'll have to process it first.

(The good news is that I found this after discovering that it's easy to for through the list and dump it to a string.)

Sept4 - start rethinking the Back Links idea

original plan: write batch process to run daily, updating a backLinks property for each page

new idea: since canonicalLinks is in the Catalog, what if we don't cache the backLinks, but look up from the catalog on each page view? Not as fast, but easier to write. Maybe just as a first step? Or is this a waste of time? It definitely couldn't be used if there's no catalog.

Also remember that we're not going to have this running for all folders, so we need different "skins"!

• I'd need a process to update the backLinks for every folder at the same time.

  • Unless I went with the catalog-dont-cache approach!

• or do we want to build a Catalog for every folder?

  • Most of them (so far) are tiny, so it wouldn't each up much more disk space.

    • But what if that changes?

    • do I want to build the full catalog for each folder, or a minimalist version for this (and maybe for multi-node pages like Recent Changes)?

      • probably want the smallest possible - maybe I've already done a good job of that on my folder, need to check

• or, use Catalog approach, and have single skin which checks for Catalog and changes itself depending on whether it finds one.

Decision for now: use catalog-dont-cache approach, have skin test for catalog

Skin questions:

• Do I want to put the Back Links in the right column?

• Does anything else belong in the right column with them?

  • bottom Book Marks

  • upper-right stuff: Annoying Quote, buttons for Backlinks and Map, Search form

• is it time to learn CSS?

• don't forget that Front Page and the like probably need to be different

Sept 9

implement cached backlinks

• python script called backlinksList

• put backlinksList in footer code (wrapped by wikilist() to turn into links)

• do I want this showing up in Recent Changes and other listing pages??

• put script on live server, test shows good performance

• do I want the results sorted (by id)? some of the lists are long, plus that would automatically put blogbits in date order. Or, do I want to sort by last_edit_date? Decide on date, for now.

• do I want to make the list prettier? One-per-line is bad (unless it's in the right column!). More separation ( | )? Ah, blockquote. (Later changed to a table to get a border and background color contrast.)

• also just realized that it's good to have this list near the Edit button. So if I muck around with the page layout later, moving stuff to the right column, I may want to make sure this list stays near the Edit button (vertically aligned?).

User Options Recent Changes Help Page