[pmwiki-users] shopping cart cookbook - oscommerce vs PmWiki

Crisses crisses at kinhost.org
Tue Sep 19 10:17:41 CDT 2006


(oscommerce vs PmWiki)
Round 1: Fight!

I had my first experience with oscommerce and MAN am I pissed.  I  
ranted about it in my blog if anyone is interested (and YES, it  
mentions PmWiki) at http://www.eclectictech.net/etblog/ (right now  
it's the 2nd entry since I put a delicious (food!) recipe in last  
night).

Due to my horrific experiences installing oscommerce, and my joy and  
love of PmWiki, I'm thinking of creating a featured & extensible  
product shopping cart feature for the PmWiki cookbook.  Beyond my  
little PayPal recipe/hack.  I had insomnia this morning thinking up  
the markup for it, how to handle products & services for sale,  
product options, multiple vendors, etc.

I got up and attacked my whiteboard, and came up with a markup idea  
similar to wikiforms.  It would allow multiple vendors on a single  
website (and even on a single page if needed) the way I have it  
figured out right now.  It looks good on the whiteboard -- markup- 
wise, but it would take a lot of work to program the back-end.

So. Is there interest in a shopping cart system for PmWiki, with a  
lot of extensibility in mind?  I would be creating it as a cookbook  
plug-in.  How much need is there?  Patrick says he needs a shopping  
cart so I think it's time to toss ideas around.

My idea:


(:metacart:)
	(:cart XES1 seller=XES *other seller info here*:)
		(:code XyZ type=item name="Product Name" amt=123.45 desc="Product  
description" pic=http://example.com/products/pic.gif:)
			(:pic http://example.com/products/pic2.gif:)
		(:codeend:)
		(:code YYz type=coupon name="Special Offer" math=* amt=.9  
redeem="BuyMyStuff" expire=2006-07-28:)(:codeend:)
		(:code PQT type=item name="Wholesale Product" amt=40  
desc="Description" exempt pic=url:)
			(:code DEF type=discount name="25-50" range=25,50 math=- amt=50:) 
(:codeend:)
			(:code ABC type=discount name="100+" range=100, math=/ amt=2:) 
(:codeend:)
			(:code GHI type=discount name="51-99" range=51,99 math=* amt=.75:) 
(:codeend:)
			(:code NOP type=options name="Colors" select=1:)
				(:code RED type=option name="Red":)(:codeend:)
				(:code BLUE type=option name="Blue":)(:codeend:)
			(:codeend:)
			(:code QHI type=options name="Size" select=1:)
				(:code 8oz type=option name="Small" default:)(:codeend:)
				(:code 20oz type=option name="Large" math=+ amt=10.50:)
					(:code GREEN type=option name="Green" parent="Colors" math=*  
amt=1.1 exempt:)(:codeend:)
				(:codeend:)
			(:codeend:)
		(:code SVC type=service name="Install PmWiki" amt=100  
desc="description" exempt:)
			(:code Basic type=option name="Basic PmWiki Package" amt=250  
desc="description":)(:codeend:)
		(:codeend:)	
	(:cartend:)
(:metacartend:)

Notes:

exempt -> exempt from cart-wide coupons & discounts, but you can  
still nest coupons for a particular product or item
math -> the result is a calculation from the amount of the parent,  
use this mathematical function (* + - / maybe ^)  (parent_amount MATH  
amt)
range -> the discount applies to order quantities within "range".    
"range=100+" could be an alias for "range=100," since 100+ is more  
intuitive
redeem -> the code the customer must enter to add the coupon to the cart
parent -> under these circumstances add this option to the parent's  
matching option (in this case, when selecting the 20oz size, add  
Green to "Colors" -- and increase the price)
options -> default display would be drop-down, "default" is selected,  
and a "display=" option for checkboxes, radio buttons, etc. can be  
added in

There needs to be more functionality, like tax settings, checkout  
options, and payment features, etc. but this is just a starting concept



The above would be read from markup into the $metacart array  
variable, processed by the cookbook, and spat out in HTML forms, I  
think.  The order can be tracked for the entire site as an array of  
vendorcode, itemcode, optioncodes, qty, etc.  Checkout across  
multiple vendors will be the tricky part, probably requiring separate  
transactions per vendor?

A copy of the resulting array from this concept for anyone who wants  
it, or I can post it to the list for the geeks out there :)  I only  
wrote out an array -- no parsing logic.

Is this either too complicated, or too short-sighted? LOL  A cart can  
be much less complex than the sample above -- I purposely wanted to  
show a bunch of options and concepts for nesting options, a product  
with 2 pictures, etc.

Crisses
----
Regardless of what they do in the external world, multiples have  
created an elaborately rich internal one, and sometimes punishing the
wicked outside the system just makes the wicked inside the system  
feel all the more like they need to be punished also -- as outside,  
so inside.  How hypocritical to expect that the externals who made  
huge mistakes must suffer for what they did, but expect the internals  
who made huge mistakes to be absolved....it doesn't work that way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/pmwiki-users/attachments/20060919/c7bc795f/attachment.html 


More information about the pmwiki-users mailing list