[Project] shopX 2.1

Okay, so this weekend I got my feet wet with ShopX.

Personally, I think that it needs rationalization into a single snippet or module with calls to functions and processes from a file in /assets/shopx instead of multiple snippets, chunks and tvs. The problem is not that it doesn’t work but it is that there are too many opportunities for errors. The default config should be set up from a single location and only overrides should be created as chunks and snippets.

One of the gracious contribs here should put forward a vision of how they see SHOPx working, being deployed and how it will look when it is done. Right now, it seems, that people are working one fixes and making it work which is great. I would like to help see it become a mature part of the MODx puzzle so that it may be deployed and managed with ease and the wonderful flexibility of the MODx platform.

In my vision I see shopX being designed to be easy enough for an end user to install and be running in minutes but a dev could customize and push it wherever they wanted. What I see is a way for people to add and manage the catalogue items using a form not directly into TVs, User Account Management (PPP probably) Including Multiple Shipping Addresses, Order Tracking (not shipping tracking--order status), Inventory Management or Inventory Status, Tax Calculation with Zones and Multiple Tax Structures (Critical in Canada). I also think that the configs should ideally reside in a table and not in a file, snippet or a plugin. This would allow for better upgrade paths for future versions.

I know what I suggest is not simple but it is better to add some features and strip out the junk than not find out what is really essential in the first place.

What is your vision for SHOPx?

I tend to favor the multiple snippet/plugin/TV approach. That way it’s relatively straightforward to have a completely custom experience based on a solid core set of functions. For example... some folks might want a single page checkout for a digital download. I prefer a several step process for my cart that can have multiple items. If we try to be all things to all people out of the box, we run the risk of falling into the trap of death-by-featuritis.

If we have multiple little "modules" then we could possibly choose different variations of cart/minicart processors (single products vs. attributes), payment or shipping methods, tax calculation, etc.

Then again, I like to be able to more easily have a function-specific solution exactly tailored to my needs. That doesn’t mean it couldn’t be accomplished with a one-size-fits all solution though. I just don’t know if that’s the road we want to go down. (But it certainly COULD be. )

I think that ShopX should mirror the philosophy of MODx - i.e. be a framework and nothing more. From using Zencart, I know that one of the most complicated aspects is the shipping and tax calculations. These vary a great deal from store to store and it is a struggle for store systems to support all configurations. I think that ShopX should provide (for example):

An API:
- a function to get the weight of the total order
- a function to get the cost of the total order
- a function to get real time shipping quotes from places like USPS or Royal Mail (expandable by users writing seperate modules)
- a function to get the shipping address

A clean customization interface:
- a callback function to calculate the shipping cost
- a callback function to calculate the tax

The callback functions can have example code for the most common setups, but they can be easily configured. The file arrangement might be:

- shopxapi.inc.php for the API
- shopxcallbacks.inc.php for the callback functions

I think that by using the MODx philosophy of targetting people who know PHP and want to customize, it will be possible to quickly build a system that is much simpler to develop and easier to use than other complete shopping cart systems, but at the same time far more flexible than any other shopping cart system.

I’ve mentioned before that I think ShopX should have a subversion repository and a project manager. I would suggest the following:

- discuss an architecture and come to a consensus
- pick a project manager to oversee the project
- project manager writes and publishes a draft specification
- set up a subversion repository (I think Ryan can help with this)
- the project manager coordinates the development amongst multiple people

I wouldn’t underestimate the size of this project. I think that good organization is critical.

I think the ShopX framework should also provide things like:

- inventory (but only decreasing a count when products sold - use a callback function when it reaches zero and don’t allow any more purchases)
- product weight
- modular checkout - it should be possible for developers to remove a step like the shipping address or add extra options
- ability to download "virtual" products when purchased - for selling ebooks, software, etc.
- payment gateways (or at a minimum paypal IPN plus one example of a credit card gateway)
- display of shopping cart
- anything that is displayed customizable using chunks and placeholders

Just my $0.02 worth...

Andy

That sounds great Andy... very cool indeed.

During development, I think this should be a private forum as it will help keep everyone focused on getting the first version pushed through without having to field requests for feature x, y or z. Those interested in working on this, please PM me and I’ll get it set up along with the SVN bits.

I agree with Ryan’s view of the modular approach. Also I think that a collection of modular pieces (TVs, snippets, chunks, etc.) can be easily used if the documentation is good enough. If a specification is written first with the overall design then it can quickly be turned into HTML later.

Andy

Most of this has been said now, but this still stands as a response to smashingred:

I believe the wonderful flexibility of MODx comes from the fact that there are several ways of achieving the same goal; I can have a blog with just Ditto and the Manager, or I could add Jot for comments and a front-end blog entry form. I can mix and match.

With ShopX, I dislike the use of documents as products, but I should be able to use a cart and shipping module etc with minor modification. So I much prefer the idea of ShopX being modular with multiple snippets.

Sure, common functions can and should access the same include file.
And I agree with a single location for config, saved in the database and editable via a manager module, and available to all ShopX snippets so they can be consistent with currency signs etc.

But having ShopX as one snippet to which different things are passed for different purposes doesn’t make anything easier - using common functions and config locations is entirely possible with the current multiple-snippet method.

So it seems a fundamental decision needs to be made on where to store the products. As documents or in custom database tables? What are the pros and cons of each?

Documents:
Pros: Easy to use for those famliar with MODx.
Cons: Requires probably lots of TVs. Large catalogues will run into the scalability problem of MODx

Database:
Pros:Highly scaleable.
Cons: Needs a manager interface to be written and maintained by someone.

Any more?

Andy

I tend to favor the document based approach for now, primarily because I really do believe that until much more development is done, we won’t have a DB-based solution ready. In my mind, a native MODx cart solution would be more aptly suited to smaller stores where the document-based solution more likely won’t be a huge gating factor and that makes it easy to visually see (in the doctree) your store layout.

With that said, as we start to figure out what really works, I see no reason to not move to a more scalable DB-based solution.

Hey folks,

As I read the replies, I see that there are valid points to maintaining the framework as a framework and nothing more. I see that snippets, chunks and plugins are the way to go for the development of a flexible and viable addition to th MODx system. My desire for simplification stems from my want to easily deploy carts to client projects based on common setups and make minor customizations vs having to cut and paste snippets, chunks and recreate TVs every time I build a cart.

I think the solution to my own issues is that I set up a system and then package it for deployment using Resource Wizard.

Again I have let my enthusiasm get the best of me.

All the best,

Jay

Other advantages for using documents for the products:

- you can template the individual product pages
- you can add your own TVs to individual products
- you can add google analytics to each product to evalulate store performance in detail

Andy