VbzCart/docs/pieces/checkout: Difference between revisions

From Woozle Writes Code
< VbzCart‎ | docs‎ | pieces
Jump to navigation Jump to search
imported>Woozle
(→‎Elements: billing; bolded function names in declarations)
imported>Woozle
(→‎Form Render: RenderPayment)
Line 15: Line 15:
*** $oCD_Recip = $oCDMgr->RecipObject();
*** $oCD_Recip = $oCDMgr->RecipObject();
*** $oCD_Buyer->RenderContact(TRUE) // edit email/phone
*** $oCD_Buyer->RenderContact(TRUE) // edit email/phone
**** '''cart/cart.data.fg-ep.php''' trait vtCartData_EmailPhone public function '''RenderContact()'''
*** $oCD_Recip->RenderShipping(TRUE) // edit shipping address / instructions
*** $oCD_Recip->RenderShipping(TRUE) // edit shipping address / instructions
**** '''cart/cart.data.fg.recip.php''' class vcCartData_Recip public function '''RenderShipping()'''
* '''page/vbz-page-ckout.php''' class vcPageCkout protected function '''RenderBillingPage()'''
* '''page/vbz-page-ckout.php''' class vcPageCkout protected function '''RenderBillingPage()'''
** '''cart/cart-shop.php''' vcrCart_ShopUI public function '''RenderBillingPage()'''
** '''cart/cart-shop.php''' vcrCart_ShopUI public function '''RenderBillingPage()'''
Line 21: Line 23:
*** $oCD_Buyer = $oCDMgr->BuyerObject();
*** $oCD_Buyer = $oCDMgr->BuyerObject();
*** $oCD_Buyer->RenderPayment(TRUE) // edit payment information
*** $oCD_Buyer->RenderPayment(TRUE) // edit payment information
**** '''cart/cart.data.fg.buyer.php''' class vcCartData_Buyer public function '''RenderPayment()'''


===Form Capture===
===Form Capture===

Revision as of 00:56, 18 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

Code Flow

Form Render

  • page/vbz-page-ckout.php class vcPageCkout protected function RenderShippingPage()
    • cart/cart-shop.php vcrCart_ShopUI public function RenderShippingPage()
      • $oCDMgr = $this->FieldsManager();
      • $oCDMgr->FetchBlob();
      • $oCD_Buyer = $oCDMgr->BuyerObject();
      • $oCD_Recip = $oCDMgr->RecipObject();
      • $oCD_Buyer->RenderContact(TRUE) // edit email/phone
        • cart/cart.data.fg-ep.php trait vtCartData_EmailPhone public function RenderContact()
      • $oCD_Recip->RenderShipping(TRUE) // edit shipping address / instructions
        • cart/cart.data.fg.recip.php class vcCartData_Recip public function RenderShipping()
  • page/vbz-page-ckout.php class vcPageCkout protected function RenderBillingPage()
    • cart/cart-shop.php vcrCart_ShopUI public function RenderBillingPage()
      • $oCDMgr = $this->FieldsManager();
      • $oCD_Buyer = $oCDMgr->BuyerObject();
      • $oCD_Buyer->RenderPayment(TRUE) // edit payment information
        • cart/cart.data.fg.buyer.php class vcCartData_Buyer public function RenderPayment()

Form Capture

  • page/vbz-page-ckout.php: class clsPageCkout function CapturePage()
    • page/vbz-page-ckout.php: class clsPageCkout function CaptureShipping()
      • $rcCart->CaptureShippingPage();
        • cart/cart.shop.php: class vcrCart_ShopUI function CaptureShippingPage()
          • $oCD_Buyer->CaptureContact();
          • $oCD_Recip->CaptureShipping();
            • cart/cart.data.fg-na.php: trait vtCartData_NameAddress function CaptureShipping()
              • $this->InvokeNameAddressFields();
              • $this->ReceiveForm();
          • $oCDMgr->FetchBlob();
            • cart/cart.data.mgr.php: class vcCartDataManager function FetchBlob()
              • $sBlob = $this->GetBlobString();
              • $this->SetBlobArray(...)
          • $oCDMgr->UpdateBlob($oCD_Buyer);
          • $oCDMgr->UpdateBlob($oCD_Recip);
          • $oCDMgr->StoreBlob();
            • cart/cart.data.mgr.php: class vcCartDataManager function StoreBlob()
              • $sBlob = serialize($this->GetBlobArray());
              • $this->SetBlobString($sBlob);
    • page/vbz-page-ckout.php: class clsPageCkout function CaptureBilling()
      • $rcCart->CaptureBillingPage();
        • cart/cart.shop.php: class vcrCart_ShopUI function CaptureBillingPage()
          • $oCD_Buyer = $oCDMgr->BuyerObject();
          • $oCD_Buyer->CapturePayment(); // card #/exp, and I *think* name/address
          • $this->AddMissing($oCD_Buyer->GetMissingArray());
          • $oCDMgr->FetchBlob();
            • cart/cart.data.mgr.php: class vcCartDataManager function FetchBlob()
              • $sBlob = $this->GetBlobString();
              • $this->SetBlobArray(...)
          • $oCDMgr->UpdateBlob($oCD_Buyer);
          • $oCDMgr->StoreBlob();
            • cart/cart.data.mgr.php: class vcCartDataManager function StoreBlob()
              • $sBlob = serialize($this->GetBlobArray());
              • $this->SetBlobString($sBlob);
          • $this->Save();


InvokeNameAddressFields() defines which fields are handled.

Conversion

Converting the cart data to order data seems to be one of the trickiest parts to get right.

Revised code flow:

  • cart/cart.logic.php: function ToOrder_Data(clsOrder $rcOrd)
    • $tCust->CreateRecord_fromContact($idUser,$oBuyer);
    • $tCust->CreateRecord_fromContact($idUser,$oRecip);

Basically, the Cart object now supervises the creation of new records as needed. Customer objects just create customer records, not address or name or whatever.

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)

Related Pages