perlDreamer/gist:540714

## gistfile1.pl
The Cart in WebGUI has typically been an 8 screen process, with the cart itself, going to the Address Book to add a shipping address, adding an Address, telling the Book to use that Address, checking out from the cart, choosing a payment method, potentially adding another address, and then finally checking out and getting the notification.  The shipping address was required, even for buying something that didn't require shipping!  Perhaps even worse, the Cart required Javascript to work correctly.

In 7.9.4, this was changed.  The Cart is now a 2 screen process.  In step one, the contents of the cart are displayed and can be changed.  At the same time, forms for the billing address are displayed, and, if the cart contents require shipping, a shipping address form is also displayed.  There's a toggle that allows the shipping address to use the same billing address.  Just below that, shipping and payment methods dropdowns are presented.  Once the user has entered credentials and selected valid shipping and payment methods, they can checkout.

Screen #2 is the payment driver, displaying a final summary of all cart charges (shipping, taxes, shop credit changes and such), and a button to finalize the checkout.

If the browser has Javascript, then several enhancements are added, like disabling the shipping form if it isn't required of if the cart is told to use the billing address for that, too.  The address book is automatically updated as information is added, and the shipping dropdown updates with costs for each method.  Without Javascript, the correct cart summary information is displayed in screen #2, and if all information is correctly entered, the cart will stay a 2-screen process.

There are some costs for these changes.

Any custom cart template will need to be reworked to include new markup and template variables.

Since the cart screen displays the user's address book, you have to be logged in to see the address forms.  If the user isn't logged in, they can still change the contents of the cart.  However, below that, instead of address forms, there is a form for logging in and/or creating an account.

Since payment address information is collected in the cart, it is no longer necessary to do it in every PayDriver.  Address collecting code was removed from each core paydriver.  A custom payment driver could still collect information, but it would need to overwrite any information collected in the Cart.

All Payment drivers need to display summary information from the Cart, for the cases where the user doesn't have Javascript.  Some drivers, like Cash, didn't have a method for doing that, so one was added, called www_getCredentials. It method, can be inherited by all Payment drivers that don't need to collect additional billing credentials.  The getButton method must be sub-classed in that case.

Each Payment driver also now has a template, that allows Shop Admins to customize the Cart summary information, any extra form required from checkout, and a button to submit the form.
	The Cart in WebGUI has typically been an 8 screen process, with the cart itself, going to the Address Book to add a shipping address, adding an Address, telling the Book to use that Address, checking out from the cart, choosing a payment method, potentially adding another address, and then finally checking out and getting the notification. The shipping address was required, even for buying something that didn't require shipping! Perhaps even worse, the Cart required Javascript to work correctly.

	In 7.9.4, this was changed. The Cart is now a 2 screen process. In step one, the contents of the cart are displayed and can be changed. At the same time, forms for the billing address are displayed, and, if the cart contents require shipping, a shipping address form is also displayed. There's a toggle that allows the shipping address to use the same billing address. Just below that, shipping and payment methods dropdowns are presented. Once the user has entered credentials and selected valid shipping and payment methods, they can checkout.

	Screen #2 is the payment driver, displaying a final summary of all cart charges (shipping, taxes, shop credit changes and such), and a button to finalize the checkout.

	If the browser has Javascript, then several enhancements are added, like disabling the shipping form if it isn't required of if the cart is told to use the billing address for that, too. The address book is automatically updated as information is added, and the shipping dropdown updates with costs for each method. Without Javascript, the correct cart summary information is displayed in screen #2, and if all information is correctly entered, the cart will stay a 2-screen process.

	There are some costs for these changes.

	Any custom cart template will need to be reworked to include new markup and template variables.

	Since the cart screen displays the user's address book, you have to be logged in to see the address forms. If the user isn't logged in, they can still change the contents of the cart. However, below that, instead of address forms, there is a form for logging in and/or creating an account.

	Since payment address information is collected in the cart, it is no longer necessary to do it in every PayDriver. Address collecting code was removed from each core paydriver. A custom payment driver could still collect information, but it would need to overwrite any information collected in the Cart.

	All Payment drivers need to display summary information from the Cart, for the cases where the user doesn't have Javascript. Some drivers, like Cash, didn't have a method for doing that, so one was added, called www_getCredentials. It method, can be inherited by all Payment drivers that don't need to collect additional billing credentials. The getButton method must be sub-classed in that case.

	Each Payment driver also now has a template, that allows Shop Admins to customize the Cart summary information, any extra form required from checkout, and a button to submit the form.