Developing Check Out with AJAX – Part 1

This two-part series will look at the development of Magento checkout to meet the requirements of a client using Enterprise 1.13. We won’t deal with the basics of setting up modules or extending classes. I’ve an earlier series on that. Here, I want to focus on checkout’s end-to-end inner workings — a post I’ve wanted to do for some time.

This series will cover how one page checkout works, how its blocks and templates are organized, how AJAX invokes the one-page controller, instantiates block classes and refreshes page elements, how product totals are calculated and presented, and how the resultant parameters are passed to the order and Admin backend.

We’ll cover all of this in the context of a client’s requirement to add the ability to receive charitable donations in the review step of one-page checkout. You can see what was delivered in these pictures. They show the donations section before and after making a selection, in this example, a charitable donation was made of £10. You can see the live site here.

Before making a selection

After making a selection

 

As an aside – in case you were wondering why ‘Order review’ follows the ‘Delivery option’ step in the above images, the ‘Payment Information’ step was removed from checkout to meet an earlier requirement of the client. You can also see in the second picture how selecting a donation amount reveals information regarding taxation for charitable donations in the United Kingdom.

OK that’s our final destination. In this introduction, part 1 of this series, let’s first take a look at the structure of one page checkout. If you just want the solution, then skip to part 2.

In part 1 let’s try to understand the following: how is the HTML for one page checkout selected, how are the block objects which support HTML templates selected and instantiated and how is AJAX used to provide checkout section processing and refresh? If you’re only reading this because you’re interested in AJAX, then skip to the section ‘Looping the checkout step HTML in onepage.phtml’. That section and the sections which follow, ‘The Prototype JavaScript Framework’ and ‘Deploying AJAX’, will guide you through AJAX’s role in one page checkout.

Let’s start where we put items in our cart and click on Proceed to Checkout. This routes us to checkout with a url of this format: http://mystore.com/checkout/onepage/. The one page controller gets invoked based on the url pattern http://mystore.com/frontName/actionControllerName/actionMethod/. Unless the controller is extended (and ours will need to be later), the frontname ‘checkout’ maps to module Mage_Checkout, and ‘onepage’ maps to controller OnepageController.php. We don’t have an action method, so the default is indexAction(). Lets take a look at this method in Mage_Checkout_OnepageContoller to get some clues about the way in which HTML assembly for one page checkout will be triggered.

Let’s start with the controller – Onepage.php

The code $this->loadLayout() is shown in red, and is responsible for getting one-page checkout layout blocks and instantiating them ready to be used by the corresponding HTML templates. The call $this->renderLayout() shown in orange is responsible for getting and including the HTML – more on that later.

Take a look at the loadLayout method called by $this->loadLayout() in app/code/core/Mage/Core/Controller/Varien/Action.php, and you’ll find a number of interesting lines of code – shown in red.

Loading layout with the loadLayout method

These calls are responsible for getting onepage’s layout handles, so that Magento can get the blocks associated with those handles for the checkout page and then instantiate them. In my Magento instance these handles for onepage are:-

• default
• STORE_default
• THEME_frontend_nhm_default
• customer_logged_out or customer_logged_in
• customer_form_template_Handle
• checkout_onepage_index

We get the default handle on line 253. The Default handle is picked up for this and most other pages. It’s worth noting now though that if a handle name is supplied as the argument in the call to loadLayout(), then it will provide the first handle for our page rather than ‘default’. You can see this in the logic of line 253. More on this later when we use AJAX to call a controller action method that loads only blocks for a specific section of checkout.

Default is a sort of wrapper handle for all the HTML on a page. You can find the layout for this handle in app/design/frontend/enterprise/default/layout/page.xml. In case you are wondering why my instance of Magento chooses the Enterprise package for its page.xml file, rather than Base or anything else, I’ll come back to that.

Here’s the layout content of page.xml for the default handle stripped down to exclude a lot of the detail.

Interesting here is the name root for the block defined on line 35 in red. As we’ll see later, the block with the name of ‘root’ is the first block to be rendered on a page. Also interesting is the block with name ‘content’ on line 92 in orange, which is the main block containing all checkout steps as we’ll see in a moment.

Carrying on with the loadLayout method, next we get three more handles with the call $this->addActionLayoutHandles() on line 257 of app/code/core/Mage/Core/Controller/Varien/Action.php. Here’s the method called:

We get the handles STORE_default and THEME_frontend_nhm_default from lines 280 (red) and 285 (orange) respectively.

The handle checkout_onepage_index is the most interesting, and as we’ll see, this is the handle containing the blocks which will comprise the block named ‘content’ in page.xml. We get it next on line 289 in blue with the call $update->addHandle(strtolower($this->getFullActionName())). As we’ll note it mirrors the url route we took to get here. Note $this->getFullActionName(), which calls this method:

The route name (or the module name), the controller name and the action name are stored in the Request object: Mage_Core_Controller_Request_Http(). This object was instantiated way back when, i.e. App::run – _initRequest(). The request object makes it easy to collect route information.

So take note, its here in this method that the request url determines the correct handle to define the content for our page. The url http://mystore.com/checkout/onepage/ determines the handle ‘checkout_onepage_index’ as the key handle for our page.

Before we look at getting the blocks and templates associated with two of the important handles we’ve identified – default and checkout_onepage_index – let’s make mention of the two other handles, we’ll get for this page: customer_logged_out or customer_logged_in and customer_form_template_Handle.

We want a handle for either customer_logged_out or customer_logged_in. This gets added when the event controller_action_layout_load_before is fired following the call $this->loadLayoutUpdates() on line 259 of the loadLayout() method in app/code/core/Mage/Core/Controller/Varien/Action.php (above). The beforeLoadLayout method in Mage_Customer_Model_Observer is run and this code selects the handle as either customer_logged_in or customer_logged_out: $observer->getEvent()->getLayout()->getUpdate()->addHandle(‘customer_logged_’ . ($loggedIn ? ‘in’ : ‘out’)). Finally, the handle customer_form_template_Handle is also obtained as part of the loadLayoutUpdates() method.

So that in a nutshell is how we get the layout handles for our page.

Getting layout blocks

OK. you’re still with me. Next comes getting the blocks associated with those handles. The call in red $this->loadLayoutUpdates() takes care of this within Mage_Core_Model_Layout_Update’s load method: foreach ($this->getHandles() as $handle) {public function merge($handle)}.

Selecting the relevant xlm file from a hierarchy of package and theme files is achieved by calls made to methods in Mage_Core_Model_Design_Package from methods in Mage_Core_Model_Layout_Update. I’m using a workaround which allows the Enterprise package to be easily included in Magento Enterprise 1.13’s package/theme hierarchy. In particular, its this piece of code $configuration = Mage::getStoreConfig(‘design/fallback/fallback’, $this->getStore()) in the module Aoe_DesignFallback (thanks to Fabrizio Branca). It collects the desired hierarchy from the database based on what the Administrator enters into Magento Admin – System-Configuration-Design-Fallback.

A foreach loop in the _fallback() method of Mage_Core_Model_Design_Package cycles through the array of packages / themes built from what the administrator entered. It does this in package / theme sequence until it finds a file that exists using $this->validateFile($file, $params), shown in red in the code next. If the file exists, then its handles and associated blocks are used. We’ll come back to the _fallback() method again later, because as well as being used to select the relevant layout file, it’s also used to select the relevant template (phtml) file.

Checkout’s content block

We’ve seen the blocks associated with the ‘default’ handle. Here are the blocks associated with the layout handle checkout_onepage_index from app/design/frontend/enterprise/default/layout/checkout.xml.

The layout in red shows the reference to the content block we already saw in the ‘default’ handle above. So the block named ‘checkout.onepage’ and all its child blocks make up the ‘content’ of the checkout page. The associated template for ‘checkout.onepage’ is onepage.phtml as we can see on line 351. Also worth noting is that the template for the root block of the default handle is changed in lines 347 to 349 (in blue) to 1column.phtml. The main sub-blocks of ‘content’ are shown in orange with their templates, which are ‘included’ to make up each of the steps in checkout:

• login.phtml
• billing.phtml
• shipping.phtml
• shipping_method.phtml
• payment.phtml
• review.phtml

Before we take a look at onepage.phtml to see how these step templates are included, let’s complete this overview of layout loading and rendering.

Layout blocks instantiation

Before we can render the page, Magento will instantiate the blocks selected for each handle. This is the call $this->generateLayoutBlocks() in the method loadLayout in Mage_Core_Controller_Varien_Action, the great grandparent of OnepageController. This is shown in blue on line 269 for the loadLayout method shown above. The method generateLayoutBlocks() is also found in Mage_Core_Controller_Varien_Action and this in turn calls methods within Mage_Core_Model_Layout which loop through all blocks and instantiate them. We can find $block = new $block($attributes) in the Layout object’s _getBlockInstance method.

Page Rendering

Rendering starts in the indexAction() method of OnepageController.php on line 215 with $this->renderLayout(). You may need to scroll up to the first code excerpt in this post to remind yourself that this was several lines of code after $this->loadLayout. Again, like instantiation, Magento uses methods in Mage_Core_Controller_Varien_Action and hands off to Mage_Core_Model_Layout.

The call $output = $this->getLayout()->getOutput() in the renderLayout() method of Mage_Core_Controller_Varien_Action calls $this->getBlock($callback[0])->$callback[1]() in the getOutput() method, which for its most important iteration equates to $this->getBlock(‘root’)->toHtml(). (The second and final iteration equates to $this->getBlock(‘core_profiler’)->toHtml().)

Magento returns the block Mage_Page_Block_Html with getBlock(‘root’) because ‘root’ is the name of that already instantiated block of block type “page/html” within the default handle of layout. Again, scroll up to see the default handle blocks in the excerpt of code for page.xml.

So in the second part of $this->getBlock(‘root’)->toHtml(), the call is to the toHtml() method in a parent of Mage_Page_Block_Html: Mage_Core_Block_Abstract. The toHtml() method is key and is used not only by ‘root’ blocks but by child blocks called by the getChildHtml() method within an HTML (phtml) file.

Then follows a sequence of calls within methods of Mage_Core_Block_Template (bear with me, the orange is an aide–mémoire) : $html = $this->_toHtml(), $html = $this->renderView() and $html = $this->fetchView($this->getTemplateFile()). The latter of these calls in the renderView() method – $html = $this->fetchView($this->getTemplateFile()) – first gets the filename and then with fetchView() includes the file path with ‘include $includeFilePath’, where in this case $includeFilePath is equal to app/design/frontend/base/default/template/page/1column.phtml. Remember that the associated template for ‘root’ was first set in app/design/frontend/enterprise/default/layout/page.xml as page/3columns.phtml and then changed in app/design/frontend/enterprise/default/layout/checkout.xml to page/1column.phtml.

The call $this->getTemplateFile() (in blue) is also worthy of more discussion, because ultimately it hands off to a method we saw earlier in Mage_Core_Model_Design_Package: _fallback() – see the code for _fallback() above. This method was responsible for selecting the relevant layout file from our package/theme hierarchy. Now it does the same for the template file.

Rendering with getChildHtml()

Before moving on to an in-depth look at the onepage template, let’s take a look at rendering a sub-block. This uses a similar code path to the one we just saw for the root block. Let’s take the example of rendering onepage.phtml when Magento encounters $this->getChildHtml(‘content’) in 1column.phtml – which we’ve just rendered.

Following this call $this->getChildHtml(‘content’), Magento calls the toHtml() method on the ‘content’ block type. (It does this in the _getChildHtml() method of Mage_Core_Block_Abstract). For ‘content’ we know the block type is Mage_Core_Block_Text_List. You can see this in page.xml, shown already in this post: <block type=”core/text_list” name=”content” as=”content” translate=”label”>.

So the call toHtml() on Mage_Core_Block_Text_List again invokes the toHtml() method in Mage_Core_Block_Text_List’s grandparent: Mage_Core_Block_Abstract — because neither Mage_Core_Block_Text_List or Mage_Core_Block_Text (the parent) have this method. However, when we invoked the line $html = $this->_toHtml() from the toHtml() method earlier — in orange — for ‘root’ with block Mage_Page_Block_Html, the _toHtml() method in Mage_Core_Block_Template was invoked and as noted this led to our getting the template file and ‘including’ the HTML.

But here when we invoke the line from $html = $this->_toHtml() from the toHtml() method for ‘content’ with block Mage_Core_Block_Text_List, the _toHtml() method in Mage_Core_Block_Text_List is invoked. This call doesn’t just go on to get the file and include it as we see here in the following code, app/code/core/Mage/Core/Block/Text/List.php.

Here we see an interesting distinction between the operation of the block types core/template and core/text_list or Mage_Core_Block_Template and Mage_Core_Block_Text_List.

Mage_Core_Block_Template requires getChildHtml() to get its children. In contrast, as can be seen in the code in line 38 in red, Mage_Core_Block_Text_List gets the children of ‘content’ one by one and calls toHtml() (again) on line 43 in blue to have each of them rendered.

One of the children found in this instance by getSortedChildren() is ‘checkout.onepage’. (There are others, e.g. ‘customer_form_template’.) The block with name ‘checkout.onepage’ has as its block type Mage_Checkout_Block_Onepage. Mage_Checkout_Block_Onepage can trace its ancestry back to Mage_Core_Block_Template, so — and here’s the thing — when the ‘checkout.onepage’ block calls toHtml(), and within toHtml() invokes $html = $this->_toHtml(), the call is made to Mage_Core_Block_Template and the file onepage.phtml is found and the HTML within it is ‘included’.

Now of course, if onepage.phtml also has getChildHtml() calls within it, then each of these blocks will also call toHtml(). If the call is made on a block with ancestry Mage_Core_Block_Template, then the block gets rendered, otherwise with Mage_Core_Block_Text_List in its lineage, it will go through the loop in app/code/core/Mage/Core/Block/Text/List.php _toHtml() again…

Looping the checkout step HTML in onepage.phtml

OK, we’re ready to dive into onepage.phtml. Find it here: app/design/frontend/base/default/template/checkout/onepage.phtml

Much more succinct than expected perhaps? We include templates in our checkout page for each checkout step using the loop comprising lines 33 to 45. Templates are included in this loop based on step ID using the method getChildHtml() – see line 42 in red. Step ID is taken from an array $this->getSteps(), line 33, which ultimately accesses this array in the _getStepCodes method of Mage_Checkout_Block_Onepage_Abstract: array(‘login’, ‘billing’, ‘shipping’, ‘shipping_method’, ‘payment’, ‘review’). However, if the customer is logged in, then the getSteps method in Mage_Checkout_Block_Onepage removes ‘login’ from the array as we’d expect: $stepCodes = array_diff($stepCodes, array(‘login’)).

Note that all steps are hidden because of style=”display:none;” on line 41. We’re going to reveal the appropriate step HTML with some Javascript, which uses Magento’s native Prototype library (as of Enterprise 1.4). This little detour should help us later when we come to code our own AJAX functionality later on. If you can’t wait, you could always jump to part 2.

The Prototype JavaScript Framework

If you’ve not had much to do with Prototype in Magento, don’t worry, because the patterns will be similar from elsewhere. Essentially there are three steps:

Firstly, grab some files containing JavaScript code wrapped up in classes. You can see this in lines 30 and 31 in blue. Note the files are located in different places.

Secondly, instantiate the classes required to provide usable objects containing the methods we need. You can see this in line 49 and in lines 53 through 57 in blue, where we instantiate accordion and checkout objects respectively. In these lines, we’re passing parameters to a constructor, known as an ‘initialize’ function in Prototype. ‘Accordion’, as the name implies, deals with the display of checkout, whereas ‘checkout’ deals mainly with AJAX. To the accordion constructor we pass the ordered list ID, defined on line 32, and the div class defined on line 36. We’ll need these DOM markers when Magento starts playing around with what sections are displayed. To the checkout constructor we pass the accordion object – AJAX callbacks will need this when hiding and displaying sections – and some urls, needed later.

Thirdly, call methods in the new objects. You can see an example on line 51, in purple. Here you can see how prototype calls the openSection method in the accordion. Remember, all sections are closed before this method is encountered. We pass $this->getActiveStep(), with ‘opc-‘ prepended, to the method. The method selects either ‘billing’ or ‘login’ depending on whether the customer is logged in – see the getActiveStep method in Mage_Checkout_Block_Onepage which returns $this->isCustomerLoggedIn() ? ‘billing’ : ‘login’;.

Of course, we’ll call the openSection method again later when we move to another checkout step, prepending ‘opc-‘ to whatever checkout step name is targeted. In fact we call it from within the gotoSection method of the Prototype checkout class, which is part of the callback from a checkout object’s AJAX request.

Let’s take a look at the openSection method in the accordion class (js/varien/accordion.js).

In red on line 39, you can see how the string passed to the method, in this case either ‘opc-login’ or ‘opc-billing’, is used along with the class ‘.a-item’ to target the div on line 41 on onepage.phtml (see above). The contents of the div are revealed on line 40 with the openSection method using ‘contents[0].show()’. We’re selecting the element that gets found first by using an array item number of 0 in ‘contents’, although in fact there is only one element there.

Note line 41 is commented out on this instance of Magento. This would provide animation for a vertical concertina checkout. I’ve used it, but only for wide incarnations of checkout on the desktop, and then it needs adjustments to facilitate checkout step height issues. For screen widths less than 1024 pixels, I use ‘contents[0].show()’ without the animation, which looks less confusing on tablets and phones.

Ok, so at this stage we know where the content of our checkout page comes from when we move from cart to checkout. The page is populated with templates for each of its steps, with either login.phtml or billing.phtml displayed, depending on whether the customer is logged in. In the review step, we’re going to be making some changes, adding the elements and methods to allow the processing of charitable donations. So let’s take a look at the review step in more depth.

Deploying AJAX

First, how is AJAX used to process what the customer has selected in previous steps and display the review step? Let’s look at moving from checkout payment to checkout review (in fact as mentioned, in my Magento instance, we move from checkout shipping method to checkout review, but that’s another story).

Take a look at review.phtml which populates checkout’s review step.

Ok, so there’s not much to it. As is apparent, content gets loaded dynamically. As an aside, content gets loaded dynamically for the shipping method and payment steps of checkout as well. Loading content dynamically is what AJAX is good at.

So where do we find the content for the review step? Well there wasn’t much for review in checkout.xml for the checkout_onepage_index handle, only <block type=”checkout/onepage_review” name=”checkout.onepage.review” as=”review” template=”checkout/onepage/review.phtml”/>.

But if we take a look at another excerpt of xml from app/design/frontend/enterprise/default/layout/checkout.xml, we’ll see more. This is the excerpt for the handle <checkout_onepage_review>.

We’ll need to load this handle and its associated blocks and templates whenever we move to the review step in checkout. These are the blocks that get loaded dynamically.

As we can see in line 512 in orange, the immediate child block is named root with template checkout/onepage/review/info.phtml. As it’s named root, we know that the template info.phtml of this block will be rendered first and then templates of other blocks within ‘root’ starting with each of the calls to getChildHtml(). Let’s take a look at info.phtml.

In our development in part 2, we’ll revisit this to make changes and embed the HTML for the charitable donations section and some javascript too, which will enable us to trigger the refresh of review and recalculate totals based on the customer’s selection.

Let’s take a look at how the review step gets opened and processed. To achieve that, we’ll need to take a look at app/design/frontend/base/default/template/checkout/onepage/payment.phtml. This is the HTML displayed for the payment step in checkout, the step immediately before review.

Ok, a lot of code here again, but the bits that we’re interested in are in red and blue. The code on line 31 in red instantiates the payment object. Note the payment class is already in the DOM. It’s in the file js/opcheckout.js that was opened on line 31 in onepage.phtml. Scroll up to see, if you need a reminder.

Take a look at the code on line 31. Prototype is passing two arguments to the payment class’s constructor, ‘initialize’: the name of this form as shown on line 35 and the url of the action method to be run on save.

Line 47 in blue specifies the payment method that will be run when the customer clicks on the Continue button: payment.save.

First, take a look at the initialize function of the payment class in skin/frontend/base/default/js/opcheckout.js.

In blue, we can see how the form ID and the url that were passed to this constructor are stored as this.form and this.saveUrl respectively. In red, we see how the method this.nextStep with this payment object as an argument is stored for use in this.onSave. In Prototype we use the bindAsEventListener function so that the ‘this’ reference will be available when the relevant event is triggered.

So that’s what happens when the payment object is instantiated. Now let’s take a look at what happens when the customer clicks on Continue and invokes the payment.save function — also in the payment class of skin/frontend/base/default/js/opcheckout.js:

OK, here we finally see Prototype’s ‘Ajax.Request’ object. Like other javascript libraries such as JQuery, Prototype provides an Ajax object which uses the transport XmlHttpRequest with browser differences safely abstracted from the user. The request has two parameters: the first is the url of the request; the second is an array which can contain the HTTP method, callback methods and parameters.

The Ajax.Request object is instantiated on line 834 in blue. The url of the request is this.saveUrl, which, as we saw in payment.phtml, where the payment object was instantiated, is checkout/onepage/savePayment. We should also note the callback method ‘onSuccess’ on line 839 that invokes this.onSave, which is the nextStep method as we saw in the initialize function.

Finally, on line 841, we can see which parameters are passed for the request. The method Form.serialize sends the contents of this.form, which as we see from payment.phtml, where the payment object was instantiated, has the ID co-payment-form. The content of the form is just the payment method in this particular example.

JQuery users will relate to Form.serialize as the .serialize method is available in that library too. If you are interested, I looked at AJAX with JQuery in an earlier post here.

Where to now? Well the AJAX request invokes the savePaymentAction() method in OnepageController.php. Here’s the code:

In purple we can see where the method gets the posted parameters on line 474 and saves them on line 475. Critical for us here is a method invoked a little further downstream as a result of the savePayment() call. It’s this this->getQuote()->collectTotals() in Mage_Sales_Model_Quote_Payment. We’ll want to remember this call as we’ll need to use it in our solution in part 2. The call is made throughout checkout: when adding items to cart, when moving to cart view, when proceeding to checkout, and when saving each of the steps of checkout with the exception of login/register.

In a nutshell this->getQuote()->collectTotals() cycles through each of the addresses used in our quote; unless we’re using multiple shipment addresses these just happen to be a billing address and one shipping address. Within each address, Magento cycles through total collector models, each of which is used to calculate a total making up the totaling of our order. Native examples of total collector models are subtotal, shipping total, discount total, tax total and grand total. Other custom examples that I’ve developed include drop shipper shipping total, drop shipper subtotal and, as we’ll see in part two, charitable donation total.

In red on line 480, we see loadLayout(), and as we’ve already alluded to in this post, by giving the call a handle as its argument, it means that this handle rather than the default handle will be loaded. Makes sense, we’re only replacing the review block. We don’t want all of the blocks comprising default loading too. So with loadLayout(), we’ve the block objects we need and their methods, which we can call from within the templates making up the review step.

In blue, on lines 481 through 484, we build the key elements of the array $result, which will be used by the AJAX call back methods that we saw in the payment.save function of the Prototype payment class. Specifically, JavaScript will need to know which section to reveal and the HTML that comprises it.

Note _getReviewHtml() on line 484 which gets the HTML for the review step. It’s essential that we get the HTML for this page at this point, after totals have been recalculated and blocks have been loaded and instantiated. The method _getReviewHtml() runs this code: return $this->getLayout()->getBlock(‘root’)->toHtml(). This is how we render the HTML when we’re using AJAX.

Finally in this code in orange on line 501, we see where a response object is created with a body that comprises a JSON object, which in this example looks like this {“goto_section”:”review”,”update_section”:{“name”:”review”,”html”:”HTML“} — where HTML is all the prepared HTML making up the review step section.

If you’re not familiar with the response object in Magento, it is the logical counterpart to the request object. It collects headers and content so that they may be returned with the sendResponse() method in Mage_Core_Controller_Response_Http. In this method the event http_response_send_before is fired, allowing developers to modify the output with an observer before it sent. Note sendResponse() ultimately fires sendResponse() and outputBody() in Zend_Controller_Response_Abstract — if you want to trace where ‘echo’ is ultimately called.

So what happens next? We’ve already noted that ‘onSuccess’ the javascript ‘nextStep’ function is invoked on return from the AJAX request. So take a look at the code for that in the payment class of skin/frontend/base/default/js/opcheckout.js

On line 854 in orange, we use the responseText method to capture the string of name/value pairs from the returned object ‘transport’: {“goto_section”:”review”,”update_section”:{“name”:”review”,”html”:”HTML“}; then using the function eval this is converted to a JSON object for further interrogation.

On line 878 in red, we invoke the setStepResponse method on the checkout object. You may recall that the checkout object was instantiated in onepage.phtml above. See line 31 of app/design/frontend/base/default/template/checkout/onepage.phtml above.

Let’s take a look now at the setStepResponse method of the checkout class in skin/frontend/base/default/js/opcheckout.js.

In red on line 263, we replace the HTML for the element with the ID checkout-review-load with the html from the response object. The review HTML is still hidden on the page, but within the checkout object’s gotoSection method — which is called on line 278 in blue — there’s a hand off to the accordion object which takes care of revealing and hiding sections: this.accordion.openSection(‘opc-‘ + section), where section equals ‘review’. We saw the openSection method earlier in the accordion class of the file js/varien/accordion.js. Scroll up for a reminder. The method hides the payment section and displays the review section.

That’s all that we cover here. In this post, we’ve looked at checkout from end to end. We’ve seen how the checkout is loaded and rendered as we move from cart to checkout. Taking the review step as our example, we’ve seen how sections are refreshed, loaded and rendered, paying attention to how AJAX facilitates a smooth transition.

In the next post, we’ll take what we’ve learned here and apply it in the context of effectively creating a new section within ‘review’ for receiving donations input from the customer. We’ll create new blocks and templates, calculate and fetch new totals, and use AJAX to invoke custom controller methods and refresh the review section.

---