[pmwiki-users] [pmwiki-devel] ZAP shopping cart question

The Editor editor at fast.st
Wed Nov 8 12:14:35 CST 2006


On 11/8/06, Crisses <crisses at kinhost.org> wrote:
>
>
> On Nov 8, 2006, at 8:45 AM, The Editor wrote:
>
> > Hi all,
> >
> > I have more a design question than a technical question, and seeking
> > some input from more experienced programmers.
> >
> > The ZAP shopping cart system works great!  But--it saves each person's
> > order information in a page like this: Order.Caveman-2006-11-09.
> > There are some real problems however if they are not logged in.  ie,
> > it won't work.  Second, if they start their order before midnight
> > everything is erased when the clock strikes twelve. Third, if they
> > send a second order the same day, the old info is still there...
> >
> > I'm thinking I need a better approach. Is there some kind of session
> > id # I could tap into that might make a better identifier?
>
> I wish I had good answers for you, but you might want to store the
> current cart page/date in a session variable, then clear it out after
> the person's checkout?
>
> I have no problem with JS for this, but I do have a problem with the
> shopping cart system being inflexible.  Say I have a product in 10
> colors -- how will the client tell me which color they want?  What if
> green costs more than the other colors?  Or I have a product with 6
> sizes, each size at a different price and shipping weight?  Discounts
> & coupons?
>
> Your cart is fine for a very simple store, though...once you resolve
> some of those issues.  What I'm going to need VERY soon are things
> like tying in user access to PayPal subscription services, as an
> example -- so that's something I'm probably going to make as an add-
> on to the new AuthUserDBase eventually (it's finished, I have to
> upload and document it).
>
> You can look at my brainstorming about shopping cart markup at
> http://www.pmwiki.org/wiki/Cookbook/ShoppingCartProposal
> and it's associated Talk page.
>
> I thought that since PmWiki is so flexible, so should a PmWiki
> shopping cart.  It could easily blow other cart systems out of the
> water for being as simplo or complicated as needed by the store in
> question.
>
> Instead of trying to dream up every possible situation, if everything
> is TRULY modular and nest-able, the store owner can pick and choose
> components based on their needs or the peculiarities of a specific
> product/service.  I wouldn't dictate that one item is set up per-page
> (you didn't either as far as I could tell, but that was someone's
> suggestion), that only one shopping cart/store owner could be set up
> per website (someone suggested wikifields for each store -- I didn't
> like that either), that discounts and coupons are used against the
> whole cart rather than a product or group of products (I've seen that
> in some other systems), etc.  It also needed to be flexible for
> taxable vs non-taxable items (there was a european cart that looked
> promising until I noted that either you taxed everything or didn't
> tax everything -- in the States that's not realistic AT ALL).
>
> Another thing that PmWiki needs -- and it's somewhat related -- is a
> (plug-in) method of obscuring download URLs -- so that people can't
> get around buying a downloadable item by directly accessing the URL
> or giving the URL out to their friends.  Or you can require people to
> fill out a contact form before downloading your free "10 Great Ways
> to Use PmWiki" document.  This is one place where storing downloads
> in a database has some advantages, but there are other ways around it
> as well.  I'd love to work that one out.
>
> Crisses


Thanks Crisses for the input.  I hadn't noticed the info you had put
up on a shopping cart proposal, but read it just now and found it
quite helpful.  It generated some great ideas for me on how to make
the ZAPcart module far more flexible.  I wrote up a response on the
talk page but thought I would post it here as that page seems to have
been active for going on two months now, and see if it generates and
response.  Thanks again!

Posting to this a bit late, but had a few comments, in relation to ZAP
and the ZAPcart module...

1) While I wasn't thinking Mall, I do believe a way could be
configured for multiple merchants to set up separate shopping carts.
It would require you to have a configurable Order.Items page (where
item info is stored), or better yet a configurable Order group which
would make each store fully independent.

2) Sounds like the proposal you are suggesting is a bit complex, but
it may be necessary for complex needs.  The ZAPcart module is really
designed for small shops with simple needs.  But there may be other
ways to solve the flexibility needs.  Namely:

3) The javascript function can be modified by any programmer fairly
easy to calculate shipping and taxes any way desired. You could also
specify the javascript file in a SDV (or perhaps in the markup), so
different checkouts could use different approaches.  Defined in a
local config file.

4) The format of the ZAPcart order and checkout sections could be
defined in a separate PmWiki page (like ZAP's email templates), to
make them quite easy to configure.  To allow multiple kinds of forms,
I could change the markup to allow an optional pagename into the
zaporder directive. Otherwise the current default would be used.  This
*should be* easy enough to do.

5) I think, without looking closely, additional parameters could be
stored for items fairly easy and made accessible to the order and
checkout sections, and to the javascript functions the same way it is
currently done.  Basically it explodes the item info by pipes--so
other fields in that array should be just as available as the price
and name.

6) As for options for items, I don't know any *easy* way to do that.
But without too much trouble, each variations of an item could be
stored as a separate item, and a special code could be put in the
zapcart markup that would create a pulldown menu with options.  A bit
of coding but not much.

7) Things like discounts, coupons, gift certificates, shipping
options, payment options, would be more complex but could be added
*perhaps* using ZAP's conditional capabilities and/or replacement
fields.  The javascript would also have to be written to make the
appropriate changes.

8) I suppose a way could be set up for ZAP to handle inventory control
(in stock or out of stock) but I have no idea how, and would probably
rather not tackle that within the ZAPcart module.  It seems it would
be for a more industrial strength application with direct tie in's to
a company's database.  Something way out of ZAP's limited scope.

I really appreciate the conceptual work you did Crisses, but think
starting with something very simple and building extensibility into it
might be a better option.  I know the basic ZAP cart system works like
a charm and it is extremely easy to set up.  Making the various parts
of ZAP more configurable would make that same ease of use available to
much more diverse applications with minimal editing, and without
having to reinvent the entire framework.

Any thoughts?

Cheers
Caveman

PS.  What did you mean by "What I'm going to need VERY soon are things
like tying in user access to PayPal subscription services, as an
example".  Don't have a clue how this would work, but I'm interested.
I wouldn't mind having a section of my site only available to those
current on their subscriptions.  But can't see how PayPal and PmWiki
can communicate sufficiently to automate this.  How were you thinking
about going about it?




More information about the pmwiki-users mailing list