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

[Ben Wilson]

My few thoughts on the matter. First, I helped a friend set up a site
and osCommerce was a totally useless tool because of its learning
curve and his needs weren't so complex. So, I join you in fist shaking
at osCommerce.

Perhaps, one product per page? IIRC, XTodo adds variables to a page,
so you may be able to do the same. This essentially makes each page a
database entry. I suppose then you can do searches based on these
variables. Then, you could use the searchlist and pagelist markups to
help create pages---rather than use static markup. Then, (for example)
whether a product is discounted is recorded on the page. This would
make administration a bit easier. You could use PmWiki categories to
refine product lists.

For GoogleMapAPI, I found a need to streamline the markup. I ended up
using (:gma-point:), (:gma-line:), and (:gma-map:). I thought this was
a bit cleaner than (:gma type=point:). At least, it seemed more
legible. So, if you _always_ have type, you may consider using a
similar markup approach. The markup is something like Markup(x, x,
'/\(:gma-(.*?)\s(.*?):\)/e', Function($1, $2)); The Function() was a
case/switch that filtered type to the correct supporting function.

Use Farms to segregate different vendors.

Sounds like you need a discussion page to start refining requirements. :-)

Ben

On 9/19/06, Crisses <crisses at kinhost.org> wrote:
>
> (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.
> _______________________________________________
> pmwiki-users mailing list
> pmwiki-users at pmichaud.com
> http://www.pmichaud.com/mailman/listinfo/pmwiki-users
>
>
>


-- 
Ben Wilson
"All this worldly wisdom was once the unamiable heresy of some wise man." HDT