Home » Forums » Ubercart » Ideas and Suggestions

Dependent attributes?

Submitted by gajillion on Sat, 08/25/2007 - 09:12
gajillion
Posts: 33
 Joined: 08/25/2007

Is anyone working on attribute dependencies for product selection? For instance, say I sell 3 different sizes of widgets but each widget comes in a different number of colors depending on the size: 4 colors for large widgets, 3 for medium, and 2 for small. When the user selects which size widget they want on a product purchase page, the color selection pulldown should reflect only the colors available for that widget. I believe the current logic for implementing this is to have a different product for each of the size/color combinations, which is very impractical for a large enough inventory.

Is anyone working on implementing this kind of functionality? If not, would there be any interest in seeing it implemented? I've done this for a previous customer in osCommerce so I have most of the logic already. Ajax-y type functionality wasn't around way back then Smiling so I had to do it with page refreshes or reallly large javascript arrays containing all the possible attribute combinations.

I'd also be interested in tying this to the inventory module so only in-stock combinations can be selected.

Mark
permalink #1 Mon, 08/27/2007 - 12:36
heribert
Posts: 9
 Joined: 08/27/2007

Hi!

I plan to write a my own Attribute-System, that will be much more flexible, but i am very new to Drupal and especially writing modules for Drupal, so it will take a long time that I can show some results (may be january next year).

I think a few developers should plan (i will help, of course) a absolute flexible attribute system, because this part has many feature requests.
What do you think?

heribert

permalink #2 Mon, 08/27/2007 - 14:10
gajillion
Posts: 33
 Joined: 08/25/2007

Heribert - I'm not really looking for anything terribly complex. I think the attribute set up that's already there is sufficient for describing products, but what's missing - and seems to be missing in most eCommerce packages - is the ability to chain dependencies. We go live in a couple months so January is a little late for me. If no one else is already working on it, I'll probably just take a crack at it and see what I come up with.

Mark

permalink #3 Tue, 08/28/2007 - 10:47
Ryan

Posts: 5379
 Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Just wanted to offer up a simple "Go for it!" here. Smiling This would be a great addition to the attributes module, though I can see it adding some complexity to the already "busy" attributes form. Once you've got a way to specify which attributes are dependent on what, you're going to need a menu callback that can return HTML for the new options. To bring it all together, you'll need to use Javascript to detect a change on the master attribute that uses jQuery's $.post() method to communicate w/ the site to get the new options. It won't necessarily be easy, but this kind of thing is happening all over the place (for example, zones getting updated when the country is changed).

I can't imagine this working well for situations w/ more than two attributes per product.

permalink #4 Wed, 09/05/2007 - 09:45
gajillion
Posts: 33
 Joined: 08/25/2007

Err... ignore this if anyone read it. Just as I said we don't need dependent attributes, I found about 10 cases where indeed, we do.

permalink #5 Mon, 10/29/2007 - 10:51
gajillion
Posts: 33
 Joined: 08/25/2007

I've been working on this for a couple months now and I'm about 2/3rds done. That said, I'm sorry to say I'm going to bail on the entire idea for now. The reason is pretty simple: uc_attributes was not written with dependent attributes in mind, and would require a complete re-write to make it work as anything less than a complete hack.

The problem is this: uc_attributes refers to "attributes" and "options". While they are essentially the same thing, "attributes" have a few more fields, referents, and (pardon the self reference) attributes than do options. However, in order to have dependent attributes, every possible option has to be able to be treated as an attribute, which they currently aren't. This made for some horribly awkward coding where you first have to check if you're at the top layer of a potential recursion tree, deal with it as an "attribute", then start your recursion, potentially treating "options" as attributes, and, if necessary, re-write the attribute specific portion of the code.

To have dependent attributes, you would need to take all of the existing attributes and make them options, or vice-versa, either eliminating the attribute specific attributes (like 'aid'), or adding them to options. You can then create a simple mapping table of parent <-> child relationships to show the dependencies. Something like this:

parent  aid
0       1
0       2
0       3
1       4
1       5
2       6
3       7
3       8
3       9
...

Where attributes 1-3 would be treated like "attributes" currently are, and 4-5 are attributes dependent on attribute 1, 6 on 2, and 7-9 on 3. I implemented something akin to this in my hack, but working around all the vagaries and differences between an "attribute" and an "option" just became too much, and I've got to get the rest of the site up and running for now Smiling

I'll come back to this if there's still interest at a later time, but backward compatibility may become an issue.

permalink #6 Mon, 10/29/2007 - 17:57
lostcarpark
Posts: 27
 Joined: 09/22/2007

This sounds like it would be a really useful feature, but I can see how it would be difficult to build on the current attribute system. Ideally you would like a multi-way hierarchy, where selecting attribute 1 makes attributes 4, 5 and 7 available, while at the same time, selecting attribute 4 makes attributes 1 and 3 available. This means that if I'm sure I want the sweater in X-Large, I can only have red or green. On the other hand, if I have my heart set on having it in blue, I can have the choice of squeezing into a large. This could be implemented by having all the drop-downs fully populated when the page loads, but when you select an item from any list it removes items that are no longer valid from the others.

These sort of relationships are not very hard to set up in a relational database, but coming up with a clear and simple user interface can be a real challenge, and it gets more difficult as the number of attributes goes up. For two attributes, you could have a simple grid, with one set of attributes across the top, and another down the side, and a checkbox in each cell that you tick to indicate the combination is available. You'd have to come up with something else for three or more sets.

Good luck with this. It sounds very interesting, and sounds like there's a certain amount of overlap with the subproducts idea I raised in another thread.