-
- 1,193 Posts
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.
-
- 898 Posts
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.
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 ..
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.
-
- 898 Posts
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.
-
- 1,611 Posts
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!
MODX Staff
MODX Staff
MODX Staff
