Keepin in mind that the old lars-images uses image-name rather than image-id as the primary key:
proc_doc pinds_img_random_name { } {
Returns the name of a random image
} {
set image_names [util_memoize { db_list image_names { select name from pinds_images where promote_p =\
't' } } 43200 ]
set image_no [randomRange [llength $image_names]]
return [lindex $image_names $image_no]
}
And then the front page just calls pinds_img_tag -front with the random image name to display the widget.
The random book code does exactly the same thing. I also applied the old lars-ratings package to books and a few other things - it's really easy since all you need to pass the ratings widgets is an object_id. I haven't used the new ratings package but I assume the principle is the same.
As to performance, the proc could easily memoize the image description, type and dimensions to avoid a db hit altogether (since in the old lars-images the photos are just filesystem files stored with a filename of image_name), but I think the biggest gain is from avoiding randomizing across a whole table in the db.
Hmm - upgrading to OpenAcs 5? I have upgraded all my client sites to get all the great new codebase, but mark.aufflick.com is a bit too hacked for a simple upgrade - I'll have to throw the code away and just migrate the data (which would still be very painful). I suspect it will stay as is until I want to totally redesign it, but that won't be happening any time soon since I quite like it! The tabs and auto generated ascii titles took FOREVER too align properly in (nearly) all browsers. There's quite a few browser specific case statements scattered around...
