create new tag
, view all tags
I've been doing a system to keep track of the equipment on my project and keep running into the age-old problem of creating a unique topic name for a page. I don't particularly care about uniqueness, nor do I care about having a sequence number, since everything has a numbered tag put on it before I ever see it.

Apache seems to be the preferred server for TWiki, and it has a module that provides reasonably good unique IDs. Adding the following to TWiki.pm expands %UNIQUE_ID% to whatever the server provided (if it actually provides it, otherwise, it will behave like any other undefined variable):

  • New subroutine:

        # =========================
        # Change an Apache UNIQUE_ID into something more TWiki-friendly
        sub handleUniqueId()
            my $id = $ENV{'UNIQUE_ID'};
            $id =~ s/@/AT/g;

  • Add to handleInternalTags() where the other environment variables are processed:

        # Expand this only if the server provides it.  Do the if here to avoid a subroutine call.
        $_[0] =~ s/%UNIQUE_ID%/&handleUniqueId()/ge if exists $ENV{'UNIQUE_ID'};

It then becomes an easy matter to create a unique topic to hold a form:

    <form name="new" action="%SCRIPTURLPATH%/edit%SCRIPTSUFFIX%/%WEB%/">
    <input type="hidden" name="topic" value="UniqueTopic%UNIQUE_ID%" />
    <input type="submit" value="Create new Topic"/ >

One note: Apache's algorithm generates letters, digits, the hypen and the "at" sign, but nothing I've ever seen come from it contains anything but letters and digits. TWiki doesn't seem to have any problem with hyphens, but it will delete "at" signs when creating a topic. These deletions could cause a (rare) uniqueness problem because the IDs 1@234, 12@34 and 123@4 will all be cooked down to 1234. This code changes it to the string AT, which eliminates that problem by expanding it to two valid characters.

Hope that's useful to someone...

-- MarkFeit - 05 Dec 2003

Another way to create a unique topic name is to combine user name and creation date. But maybe you have a specific 'unique id format' in mind.

-- ArthurClemens - 05 Dec 2003

For our inhouse TWikiBugTrackingSystem I use something similar with a pluging that looks for the last used number and adds one.. but the remainder of the technique is the same.

-- SvenDowideit - 06 Dec 2003

The Sandbox.ChangeRequest application is an example of increasing a number by one.

A simple solution we use at work is to specify a "random" number based on the date, as in MyItem%SERVERTIME{"$ye$mo$day$hour$min$sec"}%, returning MyItem180510093510. This fails if two users try to create the same entry within a one second window (it never happened at work with over 1000 users).

-- PeterThoeny - 06 Dec 2003

The solution in Sandbox.ChangeRequest is clever, but it's an O(N) solution and has to be done every time the page containing the button is rendered, whether it's going to be used or not. That could become hairy on a web with several thousand pages and a lot of users. The %SERVERTIME% solution achieves O(1) but isn't ideal because it still has the twice-in-a-second problem.

One other hazard in all of these (mine included) is that the identifier is generated with the button, not at the time the new item is actually created. This means a browser re-using a cached page will attempt to create the same item multiple times. Try this:

  1. Visit Sandbox.ChangeRequest.
  2. Click the button to create a new request.
  3. Fill in some text, preview and save.
  4. Click your browser's Back button three times, getting you back to Sandbox.ChangeRequest.
  5. Repeat steps 2 and 3, entering different text.

If your browser cached Sandbox.ChangeRequest, text entered during the second iteration will clobber whatever was entered in the first, and if the edit lock isn't released there will be no trace of the first one in the revision history. If the edit lock is released, there will be a record of the original, but it won't show up in searches, so a change request could fall through the cracks.

The more I think about this, the more I think the right solution would be to tweak the edit script so it has a printf() style substitution for a unique ID that can be applied in the topic parameter, like this:

    http://twiki.org/cgi-bin/edit/Sandbox/?topic=ChangeRequest%25u&onlywikiname=on& ... 

It still doesn't solve the problem of having nice, short sequential numbers to use as identifiers. :-(

(I'm going to have a lot of time on the plane next month, so I may tackle this and a few other projects then.)

-- MarkFeit - 06 Dec 2003

the DeleteAccount functionality will need something similar (but from inside a script - I still like sequential numbers though..

-- SvenDowideit - 01 Jan 2004

my work implementation uses ten X's, and replaces them with the next unused number (creating a lock when the edit is started) see AllowDynamicTopicNameCreation

-- SvenDowideit - 13 Jan 2004

Ideal candidate for a trivial plugin if you ask me. Rather than talk about lots of alternatives, why not just add them to the code attached to UniqueIdPlugin ? (Just add an alternatives for the unique id generation. I've implemented 3 different ones to get things started since they're not exactly difficult to do.)

-- MS - 14 Jan 2004

actually, another alternative could be to merge this with SaveContentWithoutEdit.

-- SvenDowideit - 13 Feb 2004

I'm doing a blatant ripoff of other people's code, and tossing in a GuidPlugin that generates Globally/Universally Unique Identifiers (GUIDs/UUIDs). It uses the Perl/CPAN Data::UUID module (http://search.cpan.org/dist/Data-UUID/UUID.pm) to do all the real work, and I just re-worked MichaelSparks work to make the plugin. This is my first shot at a TWiki plugin (and contribution), so be gentle smile

- BruceDillahunty - 25 Feb 2004

OK, looks like everyone likes the idea of a unique number :), but I need it in the core distribution to do DeleteAccount. Should i make a default implementation that can be over-ridden? (I still need sequential number as my users like them)

-- SvenDowideit - 25 Feb 2004

Bumping Feature topic marked as Scheduled for CairoRelease that has 0% SpecProgress.

-- SamHasler - 20 Apr 2004

I'll defer to Dakar unless I implement it doing DeleteAccount

-- SvenDowideit - 21 Apr 2004

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2005-02-16 - CrawfordCurrie
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.