Ubercart

And just to follow up on my original question, I'm following cYu's suggestion:

But what I'm doing is creating a "grid" of products with stock level indicators instead of using the pull-down menu. Thanks for the suggestion. Once I have that working and have something I can roll out, I'll look at writing a new attribute module.

I'm not knocking anything or anyone, but what made me give up was the fact that Ubercart isn't really designed with dependent attributes in mind. When you start looking at dependent attributes, the distinction between an "attribute" and an "option" quickly disappears. Any "option" can become an "attribute" upon which some other "option" is based. When I did this in osCommerce, there wasn't any distinction between attributes and options - in fact, the concept of "attribute" didn't even exist. Therefore it was a simple matter of just creating a dependency table of

Parent Attr #, Child Attr #

where anything with no Parent Attr would be what Ubercart considers an "attribute" and everything else is considered an option. Unfortunately in Ubercart I found that attributes and options were handled differently so I ended up with a special case for every "top level" attribute. So what should have been very clean recursive functions turned into skimming the first option, and determining if it should be handled as an attribute or an option. If it was an option, then call the recursive procedure, otherwise handle it like an attribute in a different function.

The portion of code where I converted an option back and forth to a dependent attribute and not was actually pretty easy and is already done. My only database change was adding this `parent` mediumint(9) NOT NULL default 0, to uc_attributes and uc_attribute_options. But then, when it came to displaying and managing the data (specifically, modifying the code for edit/options so options with dependent attributes were displayed like attributes instead of options) it turned into a nightmarish hack-job, basically having to treat every option with dependents as a special case.

I haven't given up completely on the idea, but we're going to be launching soon (relatively speaking) and I just couldn't spend any more time on making it work. I like your idea, but with what I was able to get done, I believe I already was beyond that - only dependent options were displayed. Like I said, creating the dependencies was relatively easy. Managing, editing, and displaying them became the real trick.

I think the way to approach this is to ignore uc_attributes altogether because there's really nothing in there that's not also in uc_attribute_options. The only difference is 'aid' which just establishes a relationship between an attribute and an option. The 'parent' field does the same thing, but it's self referential - the contents of the parent field is just an 'oid' from the same table, or '0' meaning it has no parent. In the code, anything that references uc_attributes would just reference uc_attribute_options where 'parent' = 0; But that's such a huge logical difference I don't know if it would be possible to do that and still make it compatible with existing data.