Userland Radio & Frontier: fixing nextPrev errors

    Userland Radio & Frontier: fixing nextPrev errors

    nextPrev broken

    ……………………………………

    Userland Radio & Frontier: fixing nextPrev errors

    Monday 20 June 2005

    One of the most persistent vexations of using

    (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

    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:

    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.

    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/).

    This page is part of the .

    all this webring’s pages;

    another page;

    your page to this webring.

    Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me . Thanks!

    |

    |

    |

    |

    |

    |

    |

    |

    This page

    is

    1993-2006 by ,

    via the Creative Commons License. Questions and comments? Send

    to the Geek Times Webmaster. (Domain and web content hosting at .)

    Leave a Reply

    Your email address will not be published.

    Userland Radio & Frontier: fixing nextPrev errors

    Userland Radio & Frontier: fixing nextPrev errors

    nextPrev broken

    ……………………………………

    Userland Radio & Frontier: fixing nextPrev errors

    Monday 20 June 2005

    One of the most persistent vexations of using

    (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

    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:

    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.

    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/).

    This page is part of the .

    all this webring’s pages;

    another page;

    your page to this webring.

    Have you found errors nontrivial or marginal, factual, analytical and illogical, arithmetical, temporal, or even typographical? Please let me know; drop me . Thanks!

    |

    |

    |

    |

    |

    |

    |

    |

    This page

    is

    1993-2006 by ,

    via the Creative Commons License. Questions and comments? Send

    to the Geek Times Webmaster. (Domain and web content hosting at .)

    Leave a Reply

    Your email address will not be published.