[pmwiki-users] Lateral thought from a newbie

[Marc Cooper]

Joachim Durchholz said...
> Slug Shrubbers schrieb:
>  > Could PMWiki be used as a basic e-commerce/e-ordering application?
> 
> The problem is that an ecommerce application does a whole lot of things 
> that would have to be programmed in addition to (or outside of) PmWiki. 

This is very true.

> Just off the top of my head:
> * Compute taxes (usually based on the customer's residence,
>    i.e. you need to store the tax regulations somewhere)
> * Compute shipping&handling cost (often depends on weight,
>    sometimes on bulk)
> * Some countries (particularly those in the EU) require that the
>    customer has seen and explicitly agreed to your terms of service
>    (well, technically it's OK to not do that, but then your ToS simply
>    won't apply); this means that you *need* a strict fill-the-basked -
>    agree-to-ToS - present-the-invoice sequence. Having a fixed sequence
>    is the exact opposite of what a wiki does, so you'd need to program
>    the checkout sequence independently.
> * Product categories often have subcategories, so the groups don't have
>    a 1:1 mapping to product categories.
> * Some people want to feed the orders into stock management.
>    Oh, and into their invoice software, too.
> (I'm pretty sure that there are lots of other things. People have 
> written hundreds of add-ons to osCommerce.)
> 
> What PmWiki does offer is essentially a nice simple markup for product 
> pages. That's an advantage, but most shop software simply uses HTML for 
> that task - and PmWiki's collaborative aspects are mostly wasted on an 
> eShop (I say "mostly" because I can imagine shops where multiple people 
> work on the product descriptions).

Ah, but the upside with PmWiki is that all these components can be made 
to be very small and adaptable, and, with markup, very configurable.

One of the difficulties when using dedicated ecommerce software (e.g. 
osCommerce, or VirtueMart in Joomla/Mambo) is that you have to work 
within a very limited framework; while PmWiki's "framework" is far more 
flexible.

So, you often spend a lot of time hacking existing code to do what you 
need with the disadvantage that you move away from the core product; 
thus making updates/upgrades time consuming and messy, and add-ons might 
simply no longer work for you. You also have to spend a lot of time 
learning how someone else's code works.

Basically, you can use PmWiki as a template engine for the process. For 
example, to include an invoice on a page: (:invoice:). All invoices for 
a customer, (:pagelist etc :). Put the shipping value on PmWiki form: 
{$total_shipping}.

PmWiki is a superb tool for collaboration, not doubt about it - in fact, 
it might currently be the best - but a by-product of designing it to 
meet those criteria is to make it an excellent - and I dislike this word 
- "platform" for many other things. For once, the tool doesn't 
constrain, but presents innumerable opportunities.

-- 
Best,
Marc