This is cool... Keep it simple and flexible Susan.
I’m here supporting you. Hope I can do something later on.
C ya...
and Good JOb!!!
Wendy Novianto
-
☆ A M B ☆
- 24,524 Posts
The catalog is simple enough, just a creative use of the MODx document tree structure, menu snippets and NewsListing snippet calls.
The plugin keeps track of the user’s activity by loading the POST returns into the SESSION.
The mini-cart snippet uses these SESSION values to generate the display of purchases with a running total.
The checkout cart snippet does the same, with the addition of a bunch of TVs that can be edited from the checkout document.
The checkout page has two TVs to contain the option blocks, one for shipping options and one for payment options. The payment options block won’t show until a shipping option has been selected.
Each shipping option requires a TV to provide the radio button option and do any other processing to determine shipping costs, setting the result as a hidden input field, then on postback if its button was set the plugin adds that to the SESSION. The checkout snippet then adds the shipping costs and generates the second part of the order.
Each payment option requires two TVs, one to provide the option radio button, and the other to handle the payment function if its option button was selected. This will make it easy to add payment options by creating two new TVs, one for the button and one for the actual payment processing. This version does not require registration, nor does it permanently store any user information.
So while it contains a number of various parts, it’s designed to be modular in the extreme, and to use as many MODx features to advantage as possible. And most of the parts can be omitted if you like; for example if you only have one payment method, just stick it in the Checkout document and skip the payment button and processing TVs; likewise with the shipping options. If you want to skip the mini-cart, you’ll need to add a link somewhere to the Checkout document, and a link or button on the checkout document so the user can clear his cart. Eventually that checkout cart will have form capabilities to change the quantity, or remove individual items.
What can I say Susan : not only do you created this great thing from scratch, but here you are writing the doc at the same time... do you sleep sometime ??
;D
.: COO - Commerce Guys - Community Driven Innovation :.
MODx est l'outil id
lol... yeah apparently they don’t !
I didn’t know this was a no-sleep-bug-squashing-code-writing-team of ninjas
Quote from: rthrash at Nov 29, 2005, 05:11 PMNinjas do not sleep. 
.: COO - Commerce Guys - Community Driven Innovation :.
MODx est l'outil id
Just wanna thanks for all the hard work.
Keep it up guys...
Sincerely,
Wendy Novianto
-
MODX Staff
- 12,272 Posts
Susan... got that PayPal thing much more cleaned up and almost done now, if you want to toss in IPN and webuser account creation into the mix.
Ryan Thrash, MODX Co-Founder
Follow me on Twitter at @rthrash or catch my occasional unofficial thoughts at thrash.me
-
☆ A M B ☆
- 24,524 Posts
Well, I’ve manage to get a rather crude email order form working. Has some rudimentary input validation. Needs a lot of work, but it gives an idea of how a Payment Module TV should work. Just call it at the end of your Checkout document, and put the corresponding PayCODOption TV in the Payment Options TV like this:
@EVAL
if(isset($_SESSION['order'])) {
return '
<form action="[~[*id*]~]" method="post">
<fieldset id="scPaymethods">
[*PayCODOption*][*PayCreditCardOption*]
<input type="submit" class="button" name="paymethod" value="Select Payment Method" />
</fieldset>
</form>
';
}
(yes, I know the names are a bit different than the package below, I will be updating it shortly)