VbzCart/docs/pieces/checkout: Difference between revisions

From Woozle Writes Code
< VbzCart‎ | docs‎ | pieces
Jump to navigation Jump to search
imported>Woozle
m (Woozle moved page VbzCart/checkout to VbzCart/pieces/checkout without leaving a redirect: reorg)
imported>Woozle
(moved obsolete stuff to archive subpage)
Line 7: Line 7:
* Send notification email to customer and store when order is placed
* Send notification email to customer and store when order is placed
==Related Pages==
==Related Pages==
* [[vbzwiki:VbzCart/checkout]]: what the checkout sequence looked like in the Perl version
* [[/archive]]: outdated stuff
==Notes==
==Elements==
===Navigation===
===Navigation===
It looks like the best way to handle form navigation is to have constant control names for the "back" and "next" buttons and to include the name of the submitting form in a hidden field.
It looks like the best way to handle form navigation is to have constant control names for the "back" and "next" buttons and to include the name of the submitting form in a hidden field.
Line 20: Line 20:
** If this page has been submitted previously, then the stored data should be checked
** If this page has been submitted previously, then the stored data should be checked
** If this page is being re-loaded because the user requested a forward move while leaving one or more required fields blank, then the submitted data must be checked (this rule can be simplified by storing it first and then always checking stored data)
** If this page is being re-loaded because the user requested a forward move while leaving one or more required fields blank, then the submitted data must be checked (this rule can be simplified by storing it first and then always checking stored data)
===Address Resolution===
It's probably a bit of a frill, but I wanted to avoid creating unnecessary contact information records (address, phone, email, name) when customers check the "ship to self" or "card address is shipping address" checkboxes. The following are some written notes on how the resolution works -- which pieces are copied under what circumstances, and what the temporary storage structures look like:
[[File:2009-11-15 VbzCart address resolution.adj.jpg|300px|left]]'''2009-11-19 Update''': The Person's Contact information should always have an Address object if there is one -- pointing to the Card's Address object if necessary. Otherwise we have to have more complicated to code to go looking for the Card.Address if there is no Contact.Address.
'''2009-11-28 update''': Each Person object should also have a Name node directly underneath, pointing to the Name node of whichever Address object seems appropriate. (Some Person objects won't have Addr nodes under some circumstances.)

Revision as of 15:05, 4 June 2016

About

The checkout subsystem handles customer interaction from the point when the customer presses "check out" on the shopping cart up to the point where the order is placed ("finish" button in old system).

Requirements

  • Record shipping information
  • Record payment information
  • Prevent customer from proceeding if required fields are missing or contain invalid data
  • Send notification email to customer and store when order is placed

Related Pages

Elements

Navigation

It looks like the best way to handle form navigation is to have constant control names for the "back" and "next" buttons and to include the name of the submitting form in a hidden field.

For the 2009 rewrite, I initially tried to have the "back" and "next" buttons specify the target form, removing the need for the submitting-form-identifier, but this causes problems under the following circumstances:

  • determining if the user should be allowed to load the requested form when required fields in the current form have been left empty:
    • If the user is moving forward, then NO - the submitting form should be re-displayed with a message listing the missing fields
    • If the user is moving backward, then YES - the requested form should be displayed regardless
  • determining the status of the data on the target page, so as to display the proper status message (indicating what fields, if any, are missing):
    • If this page has never been submitted, then no message should be displayed
    • If this page has been submitted previously, then the stored data should be checked
    • If this page is being re-loaded because the user requested a forward move while leaving one or more required fields blank, then the submitted data must be checked (this rule can be simplified by storing it first and then always checking stored data)