Treasure Chest 2: Scalability vs End user convenience.

[Guest]

Welcome, Guest. Please login or register.
Did you miss your activation email?

1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[ChuckTrukk]

I agree with therebe, the best solution would be an ecommerce API with:
- onAddtoBasket
- onRemovefromBasket
- onAddtoCart
- onRemovefromCart
- onUpdateCart
- getShipping
- calculateTotalPrice
- calculateTax
- onBeforePayment
- onPaymentComplete

I think Ryan is correct that how the products are setup should be flexible. Some would want to use ditto and each product is a document, some would want to use an external db, some would want to use a module.

This would be a framework for developers to customize the cart. One place virtuemart has a good idea is their management for choosing shipping methods, taxes, discounts (tho the implementation is buggy), and I could see where a module for the global shopping cart configs could be populated would be nice (or snippet params, or even a parent doc with TVs).

I've not seen 2 shopping carts that have the same requirements- they're like snowflakes and fingerprints. So a flexible, open API would be best.

Chuck

[rthrash]

- onAddtoBasket
- onRemovefromBasket
- onAddtoCart
- onRemovefromCart

Chuck, what's the difference in those two sets of events?

Also, I really think there needs to be some additional events centered around shipping, if that's the ultimate way this would work. Probably an onBeforeShip and onShipComplete. That way you could send tracking numbers back to the client along with a final invoice, or do authorization captures, and actual processing of credit cards more in line with how Visa/MC say you should do it (only charge when the item actually goes out the door).

[ChuckTrukk]

I agree with you that there should be some additional events, especially onBeforeShip, onShipComplete.

- onAddtoBasket
- onRemovefromBasket
- onAddtoCart
- onRemovefromCart

Chuck, what's the difference in those two sets of events?

I was thinking onAddtoBasket is adding the products to the basket from the product page. And onRemovefromCart, onUpdateCart would be looking at the actual cart/checkout page. (onAddtoCart is probably not necessary).

[Dr. Scotty Delicious]

I like the way this discussion is developing.

If I may generalize for a moment, and try to capture the highlights so far:

• Focus on API as a collection of loosely coupled, easily extendable modules
• Define a standard group of MODx System Events
• Don't limit the end user by pigeon-holing into one paradigm

I guess the above list could be a "Mission Statement", so maybe that is a good place to start? Get the project goals in a list like this?

-sD-
Dr. Scotty Delicious, DFPA.

[rthrash]

I agree with you that there should be some additional events, especially onBeforeShip, onShipComplete.

...

I was thinking onAddtoBasket is adding the products to the basket from the product page. And onRemovefromCart, onUpdateCart would be looking at the actual cart/checkout page. (onAddtoCart is probably not necessary).

An event based e-commerce system that totally ignores the catalog (how counterintuitive!) with some basic "modules" implemented would be super-yummy the more I think of it ...

I'd nuke the "basket" stuff personally, and just stick with a simpler and probably standard terminology. The following is a revised event/function list in progress, with descriptions and rough order of where they'd fall. Probably a bit overkill in spots and totally lacking in others, but just a quick brain dump:

• createCart - session or DB with expiration flag; could also be used for wishlists, wedding/baby registries, etc.
• onAddtoCart - putting something in your cart/basket, from the catalog
• onRemovefromCart - removing line items from the cart itself
• onUpdateCart - updating line items from the cart itself
• getCartLine - reference individual cart line items
• modifyCartLine - modify individual cart line items; useful for applying per-line qty discounts, trap for alternate shipping handling (e.g., drop shipped items), etc.
• calculateOrderSize - where total weight, price and piece count is calculated; could be used to calculate qty or dollar volume discounts, etc.; also for shipping estimates based on total shipping weight
• getShippingMethods - available shipping methods (per line item, taking inventory availability into account?)
• getShipping - determines shipping cost based on weight and shipping method
• onStartCheckout - moving from the cart/catalog into the checkout process; could be used to switch payment options based on customer type (wholesale vs. retail) or trap the cart to send to alternate checkout flows
• onBeforeCalculateOrderTotal - could apply coupons at this point, or calculate quantity/dollar based on iterating through each item via getCartLine (yes this provides multiple points to check for modifying cart line items, and multiple ways to handle discounting and promotions ... pick what works best for you)
• calculateTax - calls getCartLine to determine if tax applies to each line
• calculateTotalPrice - sums all product, shipping, handling, tax and any other items inserted at onStartCheckout or onBeforeCalculateOrderTotal
• onBeforePayment - trap for previous payment errors (e.g., offer to use a different card based on error codes) or insert other logic here
• onPaymentComplete - when payment or authorization processes finishes; could post to accounting system here
• onBeforeShip - event provided to modify shipping parameters based on logic and calling each getCartLine to determine costs based on logic (e.g. takes special shipping per line item into account); also could do rate shopping here, or splitting back-ordered items off to new orders
• shipItem - when item is paid for and optionally logged to the shipping system (could do the capture part of authorize and capture here)
• onShipComplete - immediately after shipping, includes tracking information; could post to accounting system here, too if it suits our business better

[Dr. Scotty Delicious]

Ryan,
Your list seems like a combination of system events to be invoked, and methods to be implemented?
I assume the items in your list that start with "On" would be system events that in your experience would be helpful for an e-commerce system, and the others would be Treasure Chest class methods that could be implemented by default, and easily overridden by sub-classing and then specifying the subclass in the snippet call.

-sD-
Dr. Scotty Delicious, DFPA.

[therebechips]

An event based e-commerce system that totally ignores the catalog (how counterintuitive!) with some basic "modules" implemented would be super-yummy the more I think of it ...

I'm loving the idea of it being event driven, however I'm not sure you could really ignore the catalogue entirely. You would still need some cross referencing to allow products to be in multiple categories, to match options to one or more products, to build product 'kits', and to allow for cross selling. I know this is all possible with MODx documents representing products with TVs to create references - and in fact I wrote the snippet Related as an attempt to provide for one-to-many and many-to-many relationships like this while maintaining referential integrity - however I do not think it would not be truly scalable. A product table would be sensible as a long term choice, particularly when this gets upgraded to work with 0.97 and the product table crud can be fully integrated with the Manager.

The other consideration is managing orders - product data may change but customer orders are 'slices in time' of the catalogue, so a separate order table is a must.

[ChuckTrukk]

therebe,

I think the key to this idea is you can create your product and order management however you like. The event driven cart will handle the cart processing- probably with a default- but allow you to use anything to populate your cart and handle your order management. I think a product catalog module would be great (and probably be made) but the custom events are the hard part.

[rthrash]

Your list seems like a combination of system events to be invoked, and methods to be implemented?
I assume the items in your list that start with "On" would be system events that in your experience would be helpful for an e-commerce system, and the others would be Treasure Chest class methods that could be implemented by default, and easily overridden by sub-classing and then specifying the subclass in the snippet call.

Definitely a mix of events and methods and unquestionably not right in lots of spots ... more of a brain dump than anything and ready for those more coding-proficient to clean up my mess.

[netProphET]

I'm excited to read about the concept of an e-business API developing here. A few years ago I did a lot of thinking and planning on this idea (my pre-MODx years). I picture an API/framework/toolset - whatever you want to call it - as providing the pieces needed for a developer to more easily create custom e-business. Sure, it might be nice to provide some sort of reference implementation of a catalog/cart/checkout combo.. but in my mind the focus should be first on the flexibility/extensibility of the core system. Maybe the reference implementation could be useful to a large number of non-developers.. that would be great. But even greater would be if the core toolset could be used to rapidly develop a large potential set of e-business systems.

Some additional thoughts on how flexible I'd love to see this - all of which I'm sure you could all think up on your own, but for some reason I'm compelled to type ;-) ::
* tax rules can be crazy complex - they can be based on anything from the location (country/state/county) of the vendor, the location of the buyer, the location of the recipient, the location of an event or seminar, with specific adaptations for any tax regime in the world, specific attributes of products
* every store owner has a unique perspective on how to handle discounts - bundles, coupons, specials, "buy a green one and get your second red one for half price next month"..
* shipping - there can be any assortment of shipping schemas, from pre-defined rules based on weight, volume, quantity, free shipping, real-time lookups from any number of external systems, shipping to multiple locations...
* partial/down payments, ratings/recommendations.. I could go on and so could any of you, so I'll stop.

The point of the above list is not to say that I want to see a solution that can do all of that. Individual developers will create all of that stuff as they need. Any API intended for use in building e-biz solutions will need to be general enough to allow these types of things to be built. The trick is having it that general, yet having enough under the hood to really make it useful.

Going out on a limb here, but maybe the whole thing could be abstracted one level further. A core API.. and then more specialized modules (not MODx modules.. sorry for mixing terms here) that plug into the API. These would still be purely programmatic structures.. nothing to do with views/output. A developer chooses the modules that are most appropriate to their requirements, then builds their custom solution from there. So you might have a few different catalog modules to choose from. One might draw products from the document tree. One might use custom db tables. One might be an interface to Amazon products. It might be cool if these modules all exposed or perpetuated some of the core API. By way of a bad/limited example, each different catalog module might still have a ::getPrice() method that could be called by another module. Or maybe modules only communicate with each other via the core API. I'm just thinking with my fingers at this point.. I should stop.

Really looking forward to see where this goes ..

[OpenGeek]

I just want to mention that I am not a fan of using events like this to support application-specific extensions/modularity.  IMHO, all of the events should be class functions that can be simply overridden in derivative classes.  This helps reduce the overhead burden on the entire site; a lot of plugins attached to seldom used events simply is not scalable.

[ChuckTrukk]

So I've been thinking about this recently, and here's some thoughts.

The store products would be most flexible if they are individual documents because products need the following things:
- Multiple Attributes (and TV's provide this)
- Site Search (and ajaxSearch provides this)
- Site Search with TV's (and ajaxSearch provides this)
- Templating (phx + Ditto provides this)
- User roles (show this item to only this person) or even phx
    - if user is Gold Member, show prices with 10% discount)
    - MODx natively provides user roles
- FDM would be a nice option
- Ditto, jot, and MaxiGallery (very powerful, made for documents)

But I still think setting up the products shouldn't be defined. Some might want to use a module, some a seperate db, some Docs. (I would prefer modx documents most of the time BECAUSE of the meta)

As for the events, I agree with Jason when he says 'IMHO, all of the events should be class functions that can be simply overridden in derivative classes.' When I say events, I mean events like eForm has them. They are functions/classes you call onAddtoCart, onRemovefromCart, etc. When I say events, I mean functions you can call like eForm to modify the default behavior.

on a side note, I'm thinking PureEdit (www.pureedit.com) would be a good MODx module option for db stuff where you don't want the doc meta stuff.

[ZAP]

Hello all -

Sorry for the long delay in replying to this very interesting discussion; I've been offline for a while...

I've built a few SHOPx stores and what they all have in common is that they're all different ;-). And if I take the other eCommerce sites I've set up into consideration, most of those had their own peculiarities as well. In fact, the only sites that ended up using standard implementations of whatever eCommerce app we were using did so because the clients were willing to compromise their expressed wants/needs to better work within the limitations of the software.

So the main thing that I really value about SHOPx is its modularity and the ability to customize it to do whatever you want. This also makes the application more efficient and easier for clients to manage, since you only install/load modules that will actually be used. If you have no downloadable products, only ship to the US, and don't manage inventory, why should you have to wade through all that stuff in the admin interface, and why should the code need to run through all of those possible routines? And it is so much simpler to deal with all of the possible shipping methods, tax rates, and payment gateways as snippets that you can customize as necessary.

The flip side of the modularity/customization coin is the major frustration that I've had with SHOPx: Nothing is standardized. For it to be useful to others, someone (or group) would need to impose a set of standards that others could use to develop new modules and improve the existing core code. Personally I think that before we jump into specific events or classes we should try to come up with a shared data model, because if that doesn't take all possibilities into account (e.g., multiple ship-to packages, purchases with coupons/credit/memberships, etc.) then everything that is based on it will be limited as well.

I think that Ryan is absolutely correct when he says that the catalog display can be completely separated from the cart management and checkout systems. As long as the catalog page includes forms with the proper variables and values, the cart management plugin can intercept those and process them. So it makes no difference to the cart processing whether people want to use Ditto and one product per document or a snippet that generates catalog pages based on products in a separate table - both generate the HTML needed to send data to the cart processing plugin.

Personally I have always used one product per document, and this has worked well for all of our sites (including one that has over 1000 items). Our clients find this easy to manage, and it allows us to use Ditto and AjaxSearch and tvExplorer and MaxiGallery and all sorts of other standard MODx tools instead of having to reinvent the wheel. For products with multiple options (e.g., t-shirts with colors and sizes), I just use an extra TV called "outOfStockCombos" that automatically generates a list of all possible color/size combinations and lets you select any that are out of stock, and then I have snippets in my templates that check these when displaying the product's form.

But I can certainly imagine circumstances where a separate database table of products would be preferable. If you have a very large catalog, one document per item could be inefficient and cumbersome. I assume that once 0.9.7 is released we will no longer need to be very concerned about the total number of documents in the site, but regularly updating thousands of products by editing one document at a time would be frustrating and time-consuming (although a bulk import script might resolve this also).

Some sort of table would probably be necessary for proper inventory management as well, so that may be a factor that needs to be considered before developing a data model. I'm sure that admin tools could be developed to create these table views from products that were stored as MODx documents if we decide to go that way, but especially if we're querying TVs for option values and whatnot this would not be the most efficient way to work with the data. To some extent, I think that decisions like this can't be made without first deciding whether the system will be running on the current version of MODx or 0.9.7 because we can't really evaluate performance and usability trade-offs unless we do that first.

So I actually didn't vote for either of the two options because I think that ideally both should be possible and the catalog and cart management systems should be separate, although I can see how some criteria might end up forcing us to make a decision one way or the other.

Glad to see so much interest in this!

[rthrash]

Sorry for the long delay in replying to this very interesting discussion; I've been offline for a while...

For penance, you are now volunteered to make the first commit to a Google Code project for this.

[eternityweb]

I urge anyone interested in MOdx Ecommerce Integration to take a look at KiweeCommerce. It has been ou of Development for a long time, but it is back at high speed!:

KiweeCommerce is back in development and more information can be found at:

http://groups.google.com/group/kiweecommerce

and

http://code.google.com/p/kiweecommerce

and

http://www.kiweecommerce.org

THANKS!

>Michael.