[ic] One-line patch for more_link_template

Carl Bailey carl at endpoint.com
Sun Oct 18 15:28:43 UTC 2009


On Oct 17, 2009, at 5:12 PM, Jon Jensen wrote:

> On Tue, 13 Oct 2009, Peter wrote:
>
>> ... a better version:
>> my $url = tag_area(undef, undef, {
>> 	search => "MM=$arg",
>> 	form => $form_arg,
>> 	match_security => 1,
>> });
>
> Carl,
>
> Were you able to try this and did you have any comment? It would be  
> nice
> to avoid hardcoding the "scan" URL part, I guess.
>
> Jon


I've been looking at this for a while now, trying to understand why  
the above would be better.  From what I can tell, there are three ways  
to call tag_area() in this case:

1) tag_area('scan', "MM=$mv_arg", { form => $form_arg, match_security  
=> 1, }
2) tag_area(undef, undef, { search => "MM=$arg", form => $form_arg,  
match_security => 1, }
3) tag_area("scan/MM=$mv_arg", undef, { form => $form_arg,  
match_security => 1, }

All three calls return the identical URL.

Options 1 and 2 both wind up making a call to escape_scan() to compose  
the URL.  That's necessary in tag_area(), when the routine can not  
know what search variables will be coming its way.  But in the case of  
sub more_link_template(), the call is always identical, using only a  
single scan directive, MM.  So hard-coding it seems more efficient by  
eliminating the call to escape_scan().  Since none of the three  
options above is inherently more readable than the others, I vote for  
option 3 for the sake of efficiency, but I am ready to be educated if  
I have missed a reason why one of the other choices is better.

Replacing "secure => $CGI::secure," with "match_security => 1" is not  
much of a change.  All that happens in vendUrl() is that when it  
detects match_security, it sets $opt->{secure} = $CGI::secure.  
However, since using match_security is more self-documenting, I think  
this is a good enhancement, and will make the change in git-hub.

Regards,
Carl
. . . . . . . . . . . . . . . . . .
Carl Bailey
End Point Corp.
t: 919-323-8025
. . . . . . . . . . . . . . . . . .






More information about the interchange-users mailing list