[ic] Different mv_substring_match for diff. fields (resolved + patch)

[Mike Heins]

Quoting Davor Ocelic (docelic at spinlocksolutions.com):
> 
> What up gentlemen,
> 
> I've fixed the problem and have a suggestion for a patch.
> 
> To remind you what was the problem in the first place:
> 
> The problem was I couldn't get different values of mv_substring_match
> to apply to the search fields in a coordinated search. On a form like:
> 
> <input type="hidden" name="sf" value="field1">
> <input type="hidden" name="sf" value="field2">
> 
> <input type="hidden" name="su" value="1">
> <input type="hidden" name="su" value="0">
> 
> <input type="hidden" name="se" value="SEARCHSPEC">
> 
> the first value of mv_substring_match was always being used, and
> the second value ignored.
> 
> 
> I suspected having only one mv_searchspec was the problem. But I wanted
> to search for the same string in both fields, that's why I had only one
> searchspec defined.
> 
> So I tried to use SearchProfile to duplicate the searchspec like:
> 
>   searchspec= searchspec, searchspec
> 
> However, there were 2 problems:
> 
> 1) Duplicating searchspec had a nasty side effect of changing
> the search spec ifself (of course), so if a person searched for
> say, "abc", in three fields, the results page said:
> 
>  "Your search results for abc | abc | abc"
> 
> 2) Another problem was - it didn't work anyway, because SearchProfile
> ran too late in the process to influence the critical code section.
> 
> 
> Finally, reaching the core of the problem, I found that mv_coordinate
> was being slyly turned off in function Vend::Search::spec_check() if
> the number of search specs didn't match the number of search fields:
> 
> $s->{mv_coordinate} = ''
>   unless $s->{mv_coordinate} and @specs == @{$s->{mv_search_field}};
> 
> 
> So the proposed solution is:
> 
> Instead of turning off mv_coordinate, let's just ensure that the number
> of search specs matches the number of search fields. (Taking user's
> setting of mv_coordinate=1 as a sign that he wants it to happen).
> 
> Alternatively we could create a new mv_ variable to set on a form to
> get this behavior, but I don't think it's necessary.
> 
> Two benefits of this approach would be:
> 
> 1) user does not have to think about adjusting mv_searchspec himself
> 2) mv_searchspec is not modified so there's no "abc | abc | abc" problem.
> 
> 
> The proposed patch:

Can't happen. We could add an "mv_force_coordinate" or something,
but we can't just change this behavior willy nilly.

> 
> --- /home/docelic/p/interchange/lib/Vend/Search.pm  2008-01-29 11:31:11.000000000 +0100
> +++ Search.pm 2008-07-03 19:22:53.000000000 +0200
> @@ -240,8 +240,18 @@
>   my $i = 0;
>  #::logDebug($s->dump_coord(\@specs, 'BEFORE'));
> 
> - $s->{mv_coordinate} = ''
> -   unless $s->{mv_coordinate} and @specs == @{$s->{mv_search_field}};
> + # If coordinated search is requested, ensure 
> + # @specs == @{$s->{mv_search_field}}:
> + if ( $s->{mv_coordinate} ) {
> +   my $last = $#{$s->{mv_search_field}};
> +   my $i;
> +
> +   for ($i = @specs; $i <= $last; $i++) {
> +     $specs[$i] = $specs[$#specs];
> +   }
> +
> +   $#specs = $last;
> + }
> 
>   my $all_chars = $s->{mv_all_chars}[0];
> 
> 
> 
> 
> 
> _______________________________________________
> interchange-users mailing list
> interchange-users at icdevgroup.org
> http://www.icdevgroup.org/mailman/listinfo/interchange-users
> 

-- 
Mike Heins
Perusion -- Expert Interchange Consulting    http://www.perusion.com/
phone +1.765.647.1295  tollfree 800-949-1889 <mike at perusion.com>

Life may not be quite the party we hoped for, but while we
are here we might as well dance. -- Anonymous