Hey Wim, I don't have time right now to give a thorough read and response, but this is more Lyle's realm anyways. I still wanted to give a quick reply.

Believe it or not, Lyle and I were just playing around with the hierarchical select demo yesterday! I was blown away. I'll leave it up to him to do think about integration w/ attributes/options. This could certainly be helpful for other parts of the cart, like categorizing products in a hierarchical catalog taxonomy vocab.

I'll bookmark this post and revisit it if I can. Thanks so much for stopping by!

Yeah, it's pretty funny that you would bring this up the day after we found your demo. I've been impressed by the hierarchical select field ever since I first learned about it (however long ago that was). I think a lot of parts of Ubercart would benefit from using it, including attribute selection.

The questions on my mind right now are what to do with the current attribute module. Like you said, it would have to have major changes to be able to incorporate hierarchical selects. This is due to the fact that I assumed a lack of hierarchy in attributes when I wrote the module. It's a lot easier not to worry about them when you don't need them. It looks to me that we can use hierarchical selects and still keep the functionality of completely independent attributes. I just want to make sure that it's still relatively easy.

However this ends up happening, I don't expect anything to be done until everyone's ported to Drupal 6. I saw where you plan on doing that after 5.x-3.0 is done. Ubercart should be usable on D6 by then, so we've got plenty of time to discuss and think about it.

I was searching for something like this but ended up here, funny thing is that I did the search yesterday and found the thread on drupal that also had a link here.

I'm not so certain that #1 by Wim has to be code changes to UC's attribute module. The way I see it is that the uc_attributes table and the uc_attributes_options table should not be touched as these 2 tables just aggregate what options should be under a certain attributes. For example color can have, blue, green, yellow, and red, it doesn't mean that these are assigned to a product.

The attribute/options to product assignment are done in 2 different tables. uc_products_attributes and uc_product_options. again I don't see why these tables need to be change as this allows the system to know that this product get a color, size, or what have you and that under color we have blue and red of one particular product but yellow and green of various sizes for another. This only describes what is allowed for that product in terms on attributes and options

what needs to happen is another table that describes the hierarchy. For example, product 1 and 2 has size, color, and style. Product 1 has small, med, and large for size, blue, green, and red for color, and logn and short sleves for style. product 2 has same sizes, but different colors, and no styles. if the Hierarchy is described in the uc_attributes and uc_options, then every product assigned that product would be assigned that hierarchy as well. which for this example doesn't work. So a new module has to be made that would assign the hierarchy of the attributes first, i.e. size controls color, color controls style, and that is assigned to the product, not to the overall attribute. From there you go about setting product 1 attribute 1 option 2 allows attribute 2 options 1,2,3 then go to product 1 attribute 2 option 1 allows ...

The hardest part on this would be creating the forms and setting the jquery chain and the xml to make the jquery pull the data from the db, unless you statically set the data for the selects in the javascript.

What I don't see is why this has to wait until a port to drupal 6 as I don't see why it couldn't be done now. I think that the attributes have to be assigned to the product before any hierarchy can be assigned. I believe that the hierarchy has to be assigned to the products rather then the attributes to allows the most flexibility because assigning the hierarchy to the attributes themselves makes it a global thing. If you want global assignment of attributes, set up the hierarchy on a class, then assign that class to the product as it can already be done that way. as far as I can detect, when you assign it that way it just copies over to the uc_products_attributes and uc_products_options, so I imagine when a class is assigned, some hook will need to be made to detect that so that it will also copy over the hierarchy as well.

I wish I had more time to help with coding, but I barely have time to make comments some days.

hope this helps.

Granville
granville [at] kirkhamsystems [dot] com

That's the reason for my #1: I need hierarchically structured data before I can present it through HS. How that happens, doesn't matter to me

hi folks,
some weeks ago i also wrote a forum article about my need of hirachical selection of atributes. so i played around after ryan told me it could be a good idea to take HS for drupal and icorporate it to the ubercart by just playing around with some code (i´m not a coder at all ;-()
so my question to WIM is there any chance to incorporate the HS to the ubercart 1.0 with drupal 5.8 ? i have a usecase on that and would be happy to share my ideas about the functionality with you and if i can do any work to get this contribute to work with the current version i would be happy to get a hint by you - even if you need a box of beer i would spend it

thanks in advance
carsten

I'm one of the many people who desperately needs this functionality. Sounds promising and I hope to see it any time soon

I will not be doing the work that's necessary to allow for hierarchical attributes. That's UC' developers responsibility, and seems an extremely basic one to me, but for some reason it hasn't been very needed so far by anybody.
As soon as there are hierarchical attributes, I'll write the HS implementation.

So … you'll have to get feedback from the UC developers and push them, rather than me.

Any words from an UC dev?