[ic] Cookies-Enabled Checking Routine

Kevin Walsh interchange-users@icdevgroup.org
Tue Jul 2 16:26:02 2002


> >>Why is the cookies-enabled checking routine in the demo like this:
> >>
> >>	[calc]
> >>		my $cname = $Config->{CookieName} || 'MV_SESSION_ID';
> >>		$Scratch->{have_cookie} = $Tag->read_cookie($cname)
> >>			and delete $Scratch->{tried};
> >>		return;
> >>	[/calc]
> >>	[if scratch have_cookie]
> >>	[elsif scratch tried]
> >>     		You must have cookies set to leave the basket. Check out now or 
> >>forever
> >>     		lose your shopping cart.
> >>	[/elsif]
> >>	[else]
> >>		[set tried]1[/set]
> >>		[bounce href="[area ord/basket]"]
> >>	[/else]
> >>	[/if]
> >>
> >>Why isn't it simple like:
> >>
> >>[if type=explicit compare="q{[read-cookie MV_SESSION_ID]}"]
> >>[else]
> >>You must have cookies set to leave the basket. Check out now or forever 
> >>lose your shopping cart.
> >>[/else]
> >>[/if]
> >>
> >>What is the added benefit of the top one?
> >
> >It is compatible with any session id cookie name, for one. Most people
> >wouldn't change it, but you can name the cookie anything.
> >
> >In later IC versions, you could probably do:
> >
> >catalog.cfg:
> >
> >	AutoVariable  CookieName
> >
> >then
> >
> >[if type=explicit compare="q{[read-cookie __CookieName__]}"]
> >[else]
> >You must have cookies set to leave the basket. Check out now or >forever 
> >lose your shopping cart.
> >[/else]
> >[/if]
> >
> >But that requires setup changes, and the way it is works with any
> >configuration.
> 
> I totally understand what you're saying there.  But why bother with the 
> scratch variable "tried" and the bounce?  I just want to make sure I'm not 
> missing something.  Why not:
> 
> [calc]
> my $cname = $Config->{CookieName} || 'MV_SESSION_ID';
> $Scratch->{have_cookie} = $Tag->read_cookie($cname)
> and delete $Scratch->{tried};
> return;
> [/calc]
> [if scratch have_cookie]
> [else]No cookies?[/else]
> [/if]
> 
If a site's "buy now" buttons are on pages that are not controlled
by Interchange then when a user clicks on one, he will be sent to
the cart page directly.

The first visit to the cart page will result in a new session, so
the user will not have a cookie to send.  The bounce allows a quick
check to ensure that the user has cookies switched on.

In this scenario, the user may return to the "foreign" pages to
browse and/or order other items.  As these pages will not be
controlled by Interchange, a session cookie is the only thing that
will keep the cart contents intact - and so the warning is required.

Most people will be sensible enough to keep all of their products
under Interchange's control.  In this case, none of the above code
is required because a lack of cookie support will be tolerated.

I hope that makes sense. :-)

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin@cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/