[ic] mv_profile and mv_search_map

[Jamie Neil]

Mike Heins wrote:

> I think you cannot do it. A bug report was made about it long
> ago, but the solution is not easy and I left it as is. Should someone
> develop a strong streak of masochism and try and jump it to fix it,
> I would welcome that.

I have a masochistic streak a mile wide, but if _you_ think it's hard 
then it's probably near impossible for perl hacker like myself :)

> 
> It wouldn't be too big a deal to develop a [hiddens] tag:
> 
> UserTag hiddens Interpolate 1
> UserTag hiddens HasEndTag
> UserTag hiddens Routine <<EOR
> sub {
>     my $block = shift;
>     my @lines = grep /\S/, split /\n/, $block;
> 
> 	my @out;
>     for(@lines) {
> 		s/\s+$//;
> 		s/^\s+//;
> 		my ($k,$v) = split /=/, $_, 2;
> 		$v = $Tag->filter('encode_entities', $v);
> 		push @out, qq{<input type=hidden name="$k" value="$v">};
>     }
>     return join "\n", @out;
> }
> EOR

Although this would produce smaller pages before processing, the 
delivered page would still contain all the hidden input tags that I am 
trying to avoid.

No matter - it's not a big problem as I was just trying to crush my 
 >40Kb pages down a bit and thought that dropping 20+ lines of hidden 
input would make a nice contribution.

I had considered redoing _all_ my searches using sql query tags (it's 
half and half the moment) as they seem to be more flexible and I assume 
quite a bit faster too. But the only way I've found (that works) of 
using them is to embed the query in the results page which means 
creating a new page for every type of search. It would be nice if there 
was some way of returning the results of a query to a standard search 
results page.

Thanks for the speedy response BTW.

-- 
Jamie Neil | <jamie at versado.net> | 0870 7777 454
Versado I.T. Services Ltd. | http://versado.net/ | 0845 450 1254