[ic] usertag call in order actionmap?

[Mike Heins]

Quoting Jonathan Clark (jonc@webmaint.net):
> Hi
> 
> (ic 4.5.5)
> 
> I am trying to call a user tag in the Order actionmap which is defined in
> the catalog.cfg.
> 
> I think, from the docs, I should be able to use:
> 
> $Tag->my_tag('foo');
> 
> but this results in the following message delivered to the browser on
> clicking a link using the [area order [item-code]]:
> 
> ==
> Sorry, there was an error in processing this form action. Please report the
> error or try again later. (Can't use string ("") as a subroutine ref while
> "strict refs" in use at /usr/local/interchange/lib/Vend/Parse.pm line 801. )
> ==
> 
> I am trying to call a routine which updates a database to keep a list of the
> users 'favourite' items. I have this working for form based additions to the
> basket using an mv_check call. I am having problems doing the same for a
> straight link based addition.
> 
> Any pointers?

It will work if you give the parameters correctly, and if you honor database
opening requirements. (Like tagging write and running with the HOT parameter
if needed.) I have tested this with both global and catalog usertags.

I investigated this in case it was a bug, and got the following to
work just fine:

UserTag my_tag Order foo
UserTag my_tag Routine sub { return "foo=$_[0] tested" }

ActionMap  test_junk   <<EOR
sub {
    $Document->hot(1);
    push @out,'testing: os28007';
    push @out, $Tag->data('inventory', 'sku', 'os28007' );
    push @out, $Tag->data('products', 'description', 'os28007' );
    push @out, $Tag->db_columns( { table => 'pricing' } );
    push @out, $Tag->my_tag( 'bar' );
    $Document->write(join "<BR>", @out);
    return;
}
EOR

% lynx -dump http://localhost/cgi-bin/construct/test_junk

   testing: os28007
   os28007
   Disposable Brush Set
   q2 price_group sku q5 q10 q25 q100
   foo=bar tested
% 


If there is a bug, we certainly won't find it without code exhibiting the
problem.

But, as usual, any time I start really looking at things I find room for
improvement. This time I made the creation of new keys in the database
a little more trouble-free with numeric fields, removing a redundant
part of Vend::Data::set_field. 8-)

-- 
Akopia, Inc., 131 Willow Lane, Floor 2, Oxford, OH  45056
phone +1.513.523.8220 fax 7501 <heins@akopia.com>

Light travels faster than sound. This is why some people appear bright
until you hear them speak. -- unknown