According to Andrew M. Bishop:
> Geoff Hutchison <ghutchis@...> writes:
> > On Sunday, April 7, 2002, at 01:08 AM, Andrew M. Bishop wrote:
> > > Error - Choose a Group
> > >
> > > ERROR - No group_id was chosen.
> > ...
> > > Whatever the reason, the error message is not clear enough and would
> > > put off many people.
> > It seems to be a bug in the SF bug system. (How ironic.) Not surprisingly, you
> > can always report bugs to the htdig-general mailing list.
> I could if I knew that this was a possibility. There is no mention of
> this option in the htdig documentation though.
Uhm, well I guess that would be true if you didn't consider bugs.html and
FAQ.html part of the ht://Dig documentation. While they don't explicitly
state you should report bugs to the mailing list if the bug reporting
system is giving you problems, they certainly do mention the existance
of the htdig-general mailing list, and recommend using it whent you're
not sure if the problem you have is a configuration issue or a bug.
Knowing that, it's not a great stretch to use the list to report what
you think is a bug. It also seems, based on the discussion below, that
this is a configuration issue after all.
> > > Using version 3.1.6 of htdig the files header.html, footer.html,
> > > etc. that are installed for htsearch have the image location set at
> > > compile/install time.
> > This is not different from any previous version.
> No, it has always been that way.
> > > There is a variable called image_url_prefix in the configuration file
> > > but this is only used for the star images in the search results and
> > > not the ones in the header or the htdig logo in the header.
> > >
> > > The ideal solution would be to make the image_url_prefix configuration
> > > file variable available to the header and footer templates to allow
> > > run-time configuration.
> > You can already do this without any coding.
> > allow_in_form: image_url_prefix
> > Then in the form, use $(IMAGE_URL_PREFIX) as a variable.
> I don't understand this suggestion. I added 'allow_in_form:
> image_url_prefix' to the config file that htsearch uses, but there was
> no change. Where am I supposed to put the $(IMAGE_URL_PREFIX), do I
> need to edit the templates, this is not what I want to do.
OK, this I find rather confusing. You stated that "the ideal solution
would be to make the image_url_prefix configuration file variable
available to the header and footer templates", to which Geoff told you
how to do exactly that, but then you say this is not what you want to do?
How can htsearch make any variable available to the templates without
having to edit the templates to use this variable?
> > Perhaps this should be enabled by default as you suggest, but I don't see it as
> > a very significant bug as you can easily edit the header and footer HTML files
> > to your heart's content.
> The problem with this suggestion is that WWWOFFLE is using htdig as an
> add-on. People that install WWWOFFLE won't know about how to edit the
> htdig template files and I don't want to distribute the templates with
> WWWOFFLE since that ties it to specific versions of htdig.
Not necessarily. The template files themselves are not version-specific,
and when we make changes to the code that affects template handling, we
try to keep these changes backward-compatible so old templates still work.
The only drawback is that your WWWOFFLE templates won't take advantage
of new htsearch template features as they become available, unless you
periodically update your templates.
> If somebody has htdig and WWWOFFLE installed and htdig and WWWOFFLE
> are working separately then it should be possible for the two programs
> to work together. The problem is that they cannot because the htdig
> template files are specific to the URL that the htdig search uses.
> The same template files cannot be used for two instances of htdig that
> have different URLs. If there are two search forms on a server then
> the same problem occurs. A different config file and search database
> can be used, but the template files must also be duplicated which
> increases the complication of upgrading to a new version.
I don't follow you here. The whole point of making the value of
the image_url_prefix configuration file attribute accessible as a
template file variable is so that different config files, with different
settings of this attribute, can share this same template file. You can
do likewise with any other config file attribute (even attribute names
that you make up yourself) to pass other config-file-specific values to a
common template file. E.g., on my web server, I have 3 config files for
3 separate htsearch configurations (SCRC, Physiology, WCSN), and these
3 share the same set of template files, passing a few made-up attribute
names to the template files via allow_in_form to select different body
tags, headings, and enquiry addresses for the 3 configs.
I also don't use the default template files, so my templates remain the
same from upgrade to upgrade (which happens frequently when I'm testing
pre-release snapshots), but from time to time I update my templates and
config files if/when I want to make use of new htsearch features.
Gilles R. Detillieux E-mail: <grdetil@...>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/
Dept. Physiology, U. of Manitoba Winnipeg, MB R3E 3J7 (Canada)