>| What should happen in the second case is that when that tune appears
>| in a list of hits, the buttons which retrieve GIF, ps or midi would
>| be disabled, and the abc button would retrieve the whole file.
>| (I've no idea how easy that would be to implement - presumably the
>| index would need an extra field to hold the information.)
> This can be done when working with a real GUI toolkit, but to do this
> with HTML pages and CGI scripts means redirecting the user to a new
> page with the given UI properties. The other solution is to write an
> applet in Java or Python (use the Java implementation called Jython)
> that will use AWT/Swing and basically be a "real" application, though
> it runs on the clients system so it would need a way to remotely
> access the index and the actual data.
Why does it need any special software? The Tune Finder generates HTML
index pages with links that invoke CGI scripts to do the conversion.
If the links aren't put on the index pages, the user can't do those
invocations (or not without so much work it would be easier to just
get the tunes and and an ABC app and do it yourself).
A line of TuneFinder index contains a list of linked single-letter
buttons, like this one to generate MIDI:
<a
href="/~jc/cgi/abc/TuneGet?F=MIDI&U=http://rigel.csuchico.edu/~pubscout/tunes/perrie.html&X=1&T=PERRIEWERRIE&N=PerrieWerrie.midi";>M</a>
All the index-generating script needs to do, for tunes which are not to
be converted, is to replace that button with " ". SQL (I presume
that's what the database uses?) provides the means to identify which
tunes require which treatment and process them accordingly. No need for
any of that do be done on the client machine.
=================== <http://www.purr.demon.co.uk/jack/> ===================
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
