[ic] forms, profiles, checkout

[Mike Heins]

Quoting Jurgen Botz (jurgen@botz.org):
> Forms, profiles and checkout seem to be the most poorly documented part
> of IC, or at least I couldn't find very much info on them.

There is info on the pieces, and some elucidation in the tutorial.
I think there is some info in Ed LaFrance's work in ic_ecommerce.sdf,
which is available from CVS and which I have put up at:

	http://ic.redhat.com/ic/ic_ecommerce.html

The key bit of information is that all ITL tags are processed first.
Then the profile statements. So the ITL produces a profile that is then
run by Vend::Order::check_order.

If you want to write your own profile checker in a UserTag that
is pretty easy.

    &set=profile_result [my-profile-usertag]
    &fatal=yes
    profile_result=required
    &final=1

That would assign the result of your usertag to $Values->{profile_result},
and then error out if it returned 0 or blank.

Your usertag can do things like set $Session->{errors}, so its output
can be used on the checkout page.

> So I have
> some questions...
> 
> 1) The profiles of the foundation store use a variety of IC tags.  Are
>    there any restriction on what you can do in a profile?

Not really. One of the few gotchas is that you have to make sure you do
[flag type=write table=foo] on a DBM table if you reference that table
and later want to write it. Other than that, you just need to know that
CGI has not been moved to $Values at that point.

> Should I be
>    able to manipulate all the session state?  [userdb save] doesn't
>    seem to work for me in a profile.

In an mv_form_profile (which is not an order profile that allows &final)
that would be because it happens before the values are updated, and it
runs from the values.  So you are saving what was *previously* in
values.

	[update values]
	[userdb save]

would work.

In an order profile, if you are going to run userdb save you need to
make sure you flag the table write if write control is on. You should
get error log statements on that one.

> 
> 2) &final triggers the actual order processing, right?  Can that be
>    inside a conditional, i.e. can I say something like...
> 
>      [if value user_checked_box]
>         &final
>      [/if]

Well, &final=yes would work.

> 
>    ..?  And in general, how do these &thingies work, are they just 
>    subroutine calls and sure to be processed sequentially?

The only way to do sequential processing is with 

&calc=<<EOF
	$Tag->sometag();
	$CGI->{foo} = 'bar';
	etc();
EOF

That happens at profile time, after ITL time.

> 
> 3) In a profile, is there any difference between...
> 
>      &set=some_value 123
> 
>       ...and...
> 
>      [value name=some_value set=123]   ...?

One happens at profile time, the other first at ITL time.

> 
> 4) After &final processing, what is the state of the session?  Does
>    $Values get reset?  What about $Scratch?

&final just sets a flag saying that an order can be submitted. It
doesn't process the order at that time. $Values is updated
after a main profile, and before any Route profiles.

$Scratch is never touched.

-- 
Red Hat, Inc., 3005 Nichols Rd., Hamilton, OH  45013
phone +1.513.523.7621      <mheins@redhat.com>

Friends don't let friends use Outlook. -- Bob Blaylock