Re: [greenstone-devel] miscellaneous proposals

From Michael Dewsnip
DateFri, 18 May 2007 14:28:44 +1200
Subject Re: [greenstone-devel] miscellaneous proposals
In-Reply-To (464CA879-1020103-gmx-org)
Hi Jens,

Almost all of your changes are in code that I wrote, so I guess I'm the
best person to take care of them :-)
> now that our project draws near its end, i'd like to propose some of
> the changes that i frequently apply to our greenstone installations.
> maybe you can find one or another useful enough to include them in
> the standard distribution. at least, that would save me the work ;-)
>
> 1. additional option 'partition_name_length' for GenericList:
>
> { 'name' => "partition_name_length",
> 'desc' => "{GenericList.partition_name_length}",
> 'type' => "string" }
>
> pass $self->{'partition_name_length'} as second argument to
> generate_partition_start/end calls. return early from those methods
> if option is given:
>
> if ($partition_name_length) {
> return &unicode::substr($metavalue, 0, $partition_name_length);
> }
>
> description (strings.properties):
>
> GenericList.partition_name_length:The length of the partition
> name; defaults to a variable length from 1 up to 3 characters,
> depending on how many are required to distinguish the partition
> start from its end. (only applies when partition_type_within_level
> is set to 'constant_size')
>
Seems like a useful option; I'll add it in.
> 2. commented out the following line (strip trailing whitespace; line
> 247 in current CVS HEAD) from GenericList, as this broke the UTF8
> representation of, e.g., '□':
>
> $metadata_value =~ s/s*$//;
>
Thanks for pointing this out; I'll try to find an alternative way of
doing this that doesn't mess up Unicode strings.
> 3. changed BasPlug.dummy_text to be *really* dummy, since the
> provided text ("This document has no text.") leads to *illegal* hits
> when searching for, say, "text":
>
> BasPlug.dummy_text:drthnmkiuhbvf.
>
I can see your point about the incorrect search matches, but I don't
think this is the right way to solve the problem because you sometimes
see this string when viewing the document. It would be better if the
plugin didn't add any text to the document, and the C++ code displayed
the "dummy text" string if necessary when outputting the document.

I don't have time to make this change; hopefully someone in the NZDL
Project can do it.
> finally, there's a feature request that i didn't actually implement
> yet, but that we could well use in our project. sometimes, when
> using the "i'm feeling lucky" feature, we don't want to be directed
> to the first result if there are in fact multiple results (we're not
> feeling *that* lucky ;-). instead, we'd like to get the results list
> just as usual in such a case.
>
> i think, something like the following should do the trick (i'm using
> an "ifl" value of 2 to differentiate from the normal behaviour; diff
> is against current CVS HEAD):
>
> --- snip---
>
> *** src/recpt/queryaction.cpp~ 2007-05-17 15:21:36.000000000 +0200
> --- src/recpt/queryaction.cpp 2007-05-17 15:30:16.000000000 +0200
> ***************
> *** 1523 ****
> --- 1524 ----
> + if (args["ifl"] == 1 || (args["ifl"] == 2 &&
> response.numDocs == 1)) {
> ***************
> *** 1550 ****
> --- 1552 ----
> + }
>
Good idea, I'll add this in.

All the best,

Michael

--
DL Consulting
Greenstone Digital Library and Digitisation Specialists
contact@dlconsulting.com
www.dlconsulting.com