Drupal and ecommerce product attributes

I'm reticent to post here, since my half-baked musings are no longer private.  But if I don't put my work-in-progress thoughts *somewhere*, I'll lose them forever.

I've been trying to beat Drupal's ecommerce module into submission for a few days now.  I would say it's a great start and adds a necessary level of functionality to Drupal, so it's a "good thing".  But I have recommended it many times to local developers, and they ran screaming.  I suspect there are many others who do their running-and-screaming without talking to the Drupal community.  The biggest argument has been an inability to show subproducts, variations, attributes, etc.  There is work being done in this area, but I'm afraid that the fundamental architecture of the ecommerce module will hamper its ability to reach a stable, graceful solution.

I wound up reimplementing the subproducts functionality independently, because it did not break out products the way I needed them broken out.  Because I was sellling a product by quantity, I needed each subproduct to indicate a quantity of items - for the sake of fulfilment.  Initially, I tried to do this by allowing the subproducts to be packages, and I expanded packages to contain n of each product.  But imagine the workflow!

In doing this, I found I could not hook into the ecommerce product functionality, appending my data as you might append information to a node.  What I wanted to do was this:

• In the product edit form (for any product), insert fields for my functionality (similar to hook_nodeapi)

But what I had to do was this:

• Create a new product type, completely separate from  any existing product type ( myproducttype.module ). Create hook_help and various module-supporting functions.
• Return a product type of "myproducttype" in myproducttype_productapi:wizard_select
• Build form and business logic around that product type.  The user will only see my business logic if she creates a new product of myproducttype, which means my functionality is mutually exclusive from all other product modules.

This means that any functionality surrounding product variations, taxes, shipping calculations, or any other "product global" functionality must be ham-handed into the main codebase for ecommerce.  Alternatively, it means that everyone who needs these features must write a separate productapi module to accommodate their needs.

Piling new, random functionalities into ecomm-core creates a transient codebase - something you definitely DON'T want when you're handling peoples' money.  It also requires some pretty fully-baked implementations that take many use cases into account.  Hence the many, lengthy arguments about just how to handle subtypes.

The second thing that freaks people out about the ecommerce module is the large and ever-growing pile of modules.  In 4.6, it's nigh impossible to click on ALL of the correct modules that you will require on the first pass.  How many ecommerce sites will require a "hosting product?"  And how many times have you forgotten to click on address AND payment AND shipping AND cart?   As requirements and use cases grow, this problem grows.

I  would be more vocal about this if I had the time to fix it.  Instead, I'm quitely jotting my thoughts in my top-secret anonymous blog.

But, if I WERE to fix it, I would point to generalizing the ecommerce productapi.  Rather than attempting to have the productapi be cognizant of every possible permutation of products, have it establish a more workflow-driven model, and treat ALL differences as  generic attributes.  A "shipping" module would create an is_shippable setting, not react to it.  Ecommerce tools could alter the workflow and the product form without forcing them into a product type.

I'd also like to see the notion of "sub-modules", or some means of enabling functionality from within the ecommerce module without troubling drupal at large.  These sub-modules would not be permitted to use Drupal hooks directly ( _cron, _user, _node, etc.).  Instead, they are loaded by the "parent" module (ecommerce), which calls the hooks as required.  This saves on loading so many modules for such small functional gain.

There may be more to come, if I have time, get funding, or if there's feedback.