There are a variety of places that a Wi Ki'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 Wiki Web/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 URL
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.
<b>Argh, neither property is a unique list</b> --Bill Seitz, 2003/07/21 17:20 GMT<br> 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
- Most of them (so far) are tiny, so it wouldn't each up much more disk space.
- 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?).