I tried asking this in the ecommerce forum and got no takers. I am (primarily) a php guy these days, so I’ll try it here.
BACKGROUND:
I spent five years building an XML-based laboratory database for documenting wetlab experimental setups.
We made separation of GUI from backend processing a big priority. In the end we had HTML get/post forms, javascript/ajax versions and a pure Java Application front end to that database. And then, eventually, a Python/TK interface.
I’d like to find a shopping cart, preferably based on PHP/Mysql backend transaction processing, that advertises a well-known API, so I can chop away the default GUI and plug in my own home-rolled CMS. Which carts (OpenCart?) are the most cleanly written? Which would be the most convenient to modify, as above?
Designing pages in a modular fashion will allow you to add extra pages in minutes instead of hours, and reduce wasted effort keeping repeated page component like navigation bars and headers in synch.
…that’s why I want to splice my own system on top, which does just that. But really, a well designed backend would allow swapping different front ends in and out like hair-dos on a model.
I think your going to be hard pressed to find something like that. All eCommerce systems I have come across are tightly coupled to their own database table structures. The only option would be to sync data between the two applications. That might be more difficult and uncertain though than writing your own front-end with your existing custom solution.
This does seem like poor design. Backend POST processing should itself be abstracted and modularized. Processing “Add to Cart” and “View Cart” and “Check out Now” etc…should have nothing to do with display appearance on the client screen.
There should be a backend cart processing API that returns strings and numbers. An HTML/CSS front end might have to add an intermediate server-side layer that wraps those strings and numbers inside HTML/CSS fragments, for use by the client. But a Java application front end would have that intermediate GUI generation layer built into the Java Client. If the POST processing and cart schema was abstracted that way, then you could swap front ends in and out like hair do arrangements.
ok. My “Java front end” example doesn’t make much sense for a shopping cart. But it still makes a point. Schemas and codes for cart/transaction processing and GUI display should be abstracted and separate from each other. From a client perspective a shopping cart is no more than a scrollable list of mini-forms that interact with an inventory schema and a session-oriented cart-per-customer schema. Inventory, per-customer-cart and GUI schema should should be coupled to each other as little as possible.
You can preach all you want there is nothing like that which I’m aware. Having put so much work into your admin? your probably better off extending it to achieve your business goals. The admin is always the most difficult part of the puzzle anyway. That is not say building a front-end w/ gateway integration will be a cake walk but probably more concrete and reliable than the alternative of syncing data back and forth using replication. My company deals with many different third parties which syncing back and forth is required via feeds and it is always causing trouble. Granted you wouldn’t be dealing with third parties but still I don’t think it would be worth it to use an open source ecommerce system in your case. That is if I understand that the admin is completed.
Creating a store which the data source can be swapped out would be a gigantic task and could never account for all situations. There would always be cases where the interface wouldn’t be compatible with a given business requirement. If you think there is a market for it you should build it ;).
Ok ok. But please notice I didn’t say anything about swapping out the data. The backend modeling would have to be abstracted and stable. I want to swap out the front end GUI. I did spend five years developing just such a system. It wasn’t a shopping cart but it was a sophisticated (laboratory database) system. The grant that funded that project for seven years ran out when the money disappeared in 2008. But we did leave it as an operational system, with three plugable front ends. And it worked quite well. To make such a system you would have to set it as a priority goal in the beginning of the design process. Someday a team will recognize the value of it and do just that. That is a worthwhile point I think.
…if the GUI is created from a generic, abstract messaging api, which is what we did in out lab database, then you can create the GUI in any language, in any way you might want. With any quick-change appearance you might want.
A system like that would only need a plugin-wrapper layer, in order to make it a shopping cart for ANY CMS.