Frontier

Using Frontier

Extending Frontier

adding favicons

migrating websites

Using CSS

Fixing Radio 8.1

Fixing Frontier 5

nextPrev broken

err log sans timestamp

temperature conversion

our WebRing

Monday 20 June 2005

One of the most persistent vexations of using Userland Frontier (and now Radio) is that the nextPrev model is broken, broken, broken. I've been asking for this to be fixed since at least early 2000, but it never makes it up the priority list (despite Dave Winer's sweet talk about moving to a user subscription model resulting in more frequent bug-fixes).

Since I can't fix Dave I can fix the bugs. So here goes; one at a time. Note: this has been tested on exactly one machine: mine. Please backup your database and the relevant functions before replacing them.

system.verbs.builtins.html.nextPrev.buildOutline

traverses the [sub]tree specified, adding entries for each of your pages and recursing through subsequent subtrees. Wonderful.

It also stupidly adds entries for defaultFileName (canonically index.html). This is freakishly vexing.

After you build a nextPrev list you have to root through it, deleting spurious entries (but mindfully keeping entries which do exist). Rename your existing buildOutline() and then download and double-click nextPrev.buildOutline.zip to fix this generation error. Note: if you expect the defaultFileName to always be first in the visit order you'll need to manually drag that line to the first location for each [sub]tree. Still, it's better than having to find all the spurious ones.

Outstanding errors to be fixed:

1. Guest databases, even when specified to the nextPrev generation dialog box, are properly processed but ignored upon output. So your nextPrev list will never *work*. My short-term fix is to add text like

   ["hardDisk:Users:mickey:web:GeekTimes.root"].

   to the beginning of each nextPrevs line. I may try to code a fix.

2. Your [sub]tree lives in a hierarchy. If this hierarchy contains too many names with numbers (or a combination of alphas and numerics) then the nextPrev comparison fails. I used to have abstracted out a tiny test case (which was sent to Userland on 1 Aug 2001). I'll have to recreate it and try to track down the bug. I will try to code a fix for this, as it makes the whole nextPrev tool only half-useful in my hierarchy (which includes things like 2005/06/26/place/).