> > 1. In what way would the HTML be NOT hardcoded? Are you referring to the > > possibility of using a selection of templates or some other such method > > of producing unique pages from a single HTML generation programme? > > Yes. At the absolute utter minimum, I would expect a separate > .css style > file, and CSS being used extensively. That way I can fix up > the look of > the album by replacing just one file, and it's a file I only need to > develop once. > > Pity none of the album generators support that.
Ah. I've written my own "quasi"-generator and implemented CSS as I experienced the same frustrations as you. The reasons for the "quasi" naming will become more apparent below. Essentially it was a very simplistic script that has developed a lot of scope creep and it's now time to reign in the beast to fall under an actual design plan that is more modular in nature. :-) > As a next step, I'd like to see a selection of designs on > offer. Look at > a word processor, web site design package, whatever, there's > some basic > variety included. If I was writing the program, I'd make a > directory per > design, and fill it up with files containing HTML fragments and > placeholders, and any graphics files used. Placeholders (a.k.a. fixed > strings) are replaced with values when the album is created. You need > rather a lot of these variables if you want to be flexible, e.g. size > of thumbnails, a few colours, and file names of course. I started on a > script using this approach many years ago, but never made it to a > releasable state. Yes. That has been what is currently progressing as the next iteration of my script. I have been going along the lines of a "template" file to read in parameter values, that were pulled from a directory of related fragments/images/etc. This has started to get unwieldy for a variety of reasons besides the obvious one of organisation and so I was dreaming of the ideal of a template designer function. I don't have that much time to write one of these though to the quality necessary for it to be universally functional. Hence my interest in your presentation - I was hoping someone else had been here before me so I could leave my wheel design alone. No such luck, eh? > None of the album generators offer this kind of > functionality. Actually > there was one which may have started in the direction of being > customisable, but the license requires a w**k on each page, so it went > to /dev/null. (The author doesn't respond to financial offers > in return > for an acceptable license either, so it stays in /dev/null.) > > All in all it's looking not too good, this kind of software > has some way > to go. Did you have a look at the filenames digikam generates? > Functional, but not good. Hence my mark of "lousy" for its HTML. It's > nicely integrated though. Note I didn't say digikam is lousy, only its > HTML (dito for any other program AFAICT). > > In any case, whatever you choose for organising your photos, do some > very long and damn good testing, and see if it works with 10000 photos > as well after you thought it'll be fine with 100. Albums are not the > most important part here... (I use a scripted setup for organisation > btw.) So far, my script uses Perlmagick extensively to identify exif data, and to resize and/or generate thumbnails, etc to match my (rather limited so far) template tag values. Another part of the "quasi" tag is that I don't use a backend database. I "identify" exif data so that (if a file has not been descriptively named already) I can rename it to at least a date-based name rather than the camera-defined prefix-sequence names. > > 2. Although the answer to this may touch on your answer above, what > > form/s of extensibility do you regard as desirable in an HTML generator? > > Extensible *albums* :) > Invariably you're going to find that you want to add some > more photos to > an existing album. Well, you're not, until you find a program > which can > do it. You can recreate the lot from scratch though... Yes. That's where I'm at now. Your presentation was good timing as I'm at a crossroad of sorts. After realising I could only get so much data out of exif, that left having to manually describe images. I could (and have so far) renamed the files themselves and used those names to generate descriptive tags but these names are somewhat limited by OS restrictions to some effect. (That was fine when I started but has become more of a concern now). As you point out, I still have the secondary problem of having to run the script every time I modify my gallery, so, besides the website being never quite "up to date", I also have to regenerate a page or pages in it's entirety. (I only need to regenerate particular pages as I utilise a tiered directory structure and check modification times of files so that the script doesn't regenerate pages containing directory contents that have not changed). At this point, I am investigating the use of php and mysql to obtain a dynamic webgallery that could be easily searched on (something my current implementation lacks) and would solve the current descriptive naming restrictions. Porting from perl appears to be relatively straightforward. Thinking of these two as they're somewhat portable and standards-based. Before I undertook this I thought I'd find out what you guys had found and bounce some ideas around so that I didn't repeat the scope creep issue I've currently got. :-) Comments? > Volker
