next »

[smashingred]

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?

[rthrash]

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. )

[Andy Ayre]

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

[rthrash]

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.

[Andy Ayre]

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

[PaulGregory]

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.

[Andy Ayre]

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

[rthrash]

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.

[smashingred]

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

[Andy Ayre]

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

[smashingred]

RE: Doc Vs DB

I think based on what I have read about flexibility that it would be ideal to create the DB Shop Manager as an addon vs. the primary solution. Even as the Cart project grows, there will always be small sites where a doc based catalogue is best and a DB might be overkill. It still may be a good idea to save the configs in a Db table though. But like many sites I have built in PHP you can just as easily use Constants or Variables to  do the trick.

ATB,

Jay

[smashingred]

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

These are great points! I think though you could record template selection and TVs via the Manager. I am pretty sure since the pages would have to be dynamically generated with unique identifiers GA should work just fine. That being said, the doc method seems to be a nice, easy system that wouldn't hold back the advancement of the cart system for MODx and, in light of potential Core changes it makes the most sense until 1.0 is in Beta.

ATB,
Jay

[PaulGregory]

Having now read ajayre's earlier comments:

Yes. Absolutely. To expand this further: Everything should be modularised, even "display price", which may need to pull the ex-tax price, check the tax-band and display it with tax (UK B2C is usually displayed inc-VAT, UK B2B is usually displayed ex-VAT). Then everywhere that there is a price, it uses that function. Or, it may need to check the special offers, and display a strike-through 12.99 and a highlighted 7.99. All extra features need to plug in somewhere; yeah sure this stage shouldn't be collecting feature-requests but they need to be allowed for.

This all means that although there is more that can be configured, everything only needs to be configured in one location and then all add-ons can use these common functions. The left and right-hand column boxes in osC like random recent product, top 10 lists etc could each be a snippet that can be used anywhere on a MODx site, but they would pick up the ShopX settings and format data the same way as the rest of the site.

I expect that it is worth looking deeply at what MODx 1.0 allows us to do.

doc vs db

Of course, documents *are* in the db. So here we definitely need to consider MODx 1.0, as that appears to let us define a 'product' type of document and thus gives us the best of both worlds.

Really, I'd like to see ShopX be flexible as to where the product ID and various fields are coming from; it should be possible to abstract things so that they could come from either documents or a dedicated table. The majority of the shops I'm involved in have 1,000+ products; a db table would be easier to migrate to. I have one shop with 44 products, and am very tempted to move that one to ShopX.

There's always going to have to be a strong association between products and documents, and yes templating them individually (or by type) is a plus. I am also very keen to ensure that products have FURLs.

[ZAP]

WOW! Look at all that constructive energy a-flowing! This community never ceases to amaze me...

Personally I also favor keeping ShopX as modular as possible, although I think that we could package one or more default installations (digital sales only, PayPay checkout only, multiple payment and shipping methods, etc.) with some sample products and everything set up for folks who don't need much customization. I actually centralized a lot of the code into one plugin that checks for form input and sets placeholders and variables, and I actually don't think that this makes the solution any less modular. There would be some sections in this plugin that many people would want to modify or just comment out, but this seemed like the natural place to have all the common code.

I also like the document products model in general, both because it's a tried-and-true interface that clients understand and because it allows us to make use of the wealth of MODx swiss army knives (Ditto, eForm, etc.) for associated features. But I can imagine that for a 1000-product store that might make for slow menu generation and other performance issues (especially since caching may need to be off for product forms to function), so we may want to consider a table-based alternative as well. Future releases of MODx may negate this downside for very large catalogs, however.

In the current versions of ShopX that I've seen the plugin intercepts and processes the form values when a customer adds items to their cart or updates it, so programatically I don't think it matters at all whether the form that posts the variables was created from products stored as documents or in a separate table (they're just post vars).

I also think that for most people products as documents will probably work well and be the best method because it allows for easy customization of its values and options via TVs. For example, in the first store I set up with ShopX most products have seven different styles (ranging from pajama to handbag) as well as colors, sizes, etc., and they wanted customers to be able to choose from among all these dynamically with the photos and options updating as they made choices. And the one I'm doing now doesn't have fixed prices for their items; they have a minimum and maximum price range and we need to let people choose what they want to pay within that range. Neither of these would've been possible without TVs, although I guess if a separate product table existed I could've modified that and then used TVs to display the data the way I wanted it. MODx's innate flexibility allowed me to create these totally non-standard stores as if they were any other, and that's a HUGE advantage over any other cart solution I'm familiar with.

I actually forgot to mention in my post yesterday that I'll be adding the Google Analytics Goal-tracking code to my thank-you page template this week (which should be a piece of cake to do). And that I still may need to add an inventory control table to one store and I'm currently scratching my head over the best way to do that (mostly so that clients can easily update it every day - they have a lot of offline sales as well). If anyone can tell me how to create a check-box TV based on the values entered into other TVs I can probably avoid having to create a full inventory system for this site and move on to other things...

[ZAP]

Good! I was hoping this would "beat the underbrush" and scare out whoever is working on this thing! Zap, I will gladly yield to you, as well as Scotty. I am over my head on this; it's just that since I started it I feel sort of responsible for it.

I forgot to mention again that you did one helluva job getting this project going, Susan! I doubt very much that you are actually over your head, so if you have the energy to continue contributing to it (and you never seem to lack energy) then please do. I feel like I learn something every time I look over code that you've written, and I'm sure that others have had the same experience.

[sir_thomas]

does this method work with digital downloads... or is this feature a possibility with the current set up?

[ZAP]

does this method work with digital downloads... or is this feature a possibility with the current set up?

AFAIK, no one's done that yet, but it should be a simple addition to the current code (download file name in a TV and a thank you template with code to start the transfer).

[Andy Ayre]

The download page has to be protected so someone can't later revisit the same URL and get the download without paying. So maybe that needs to be tied into the web users system? But then people might share username and password info with others.

Andy

[ZAP]

Right. There are lots of ways to do this, so we'll just have to choose one or two and set them up. Carts that create user accounts could use that info to authenticate the download, and those that don't can set download approval vars in the plugin and send them via email to the customer as well (and without these vars to authenticate the download the page wouldn't do anything, so people wouldn't be able to abuse it).

[Andy Ayre]

So which part of that should be in a ShopX framework, which part is already in MODx/other snippets and which part should be user customization? I.e. where is the line drawn?

Andy