A few people have asked whether Product Attributes can act as webform components so that they appear in the webform results and can be rearranged on the webform.
I wanted to do this myself and so I've put together a patch that creates a new webform component called a Product Attribute which allows you to select a Product Attribute to display on the webform. Its probably a bit rough at the moment and can be improved upon, but I thought it was worth posting so that I could get feedback, hearing whether people think it is a good idea or not & whether it can be improved/redesigned etc.. Note that the patch stops the default behaviour of automatically displaying all the Product Attributes at the end of the webform.
Comment | File | Size | Author |
---|---|---|---|
#5 | uc_event_registration-1.5_v7.patch | 30.3 KB | willowmedia |
#1 | uc_event_registration-1.5_v6.patch | 29.15 KB | willowmedia |
uc_event_registration-1.5.patch | 22.23 KB | willowmedia |
Comments
Comment #1
willowmedia CreditAttribution: willowmedia commentedI've rolled another patch which includes the following changes:
- fixed bug when downloading data from radio buttons or attributes with no data
- added support for textfield attributes
- to preserve the pre-patch behaviour, included an upgrade script that adds product attributes to existing paidevent webforms
- creating new paidevent nodes will have product attributes added if they are found on the product class (unless we are cloning webforms)
Comment #2
AndyF CreditAttribution: AndyF commentedThanks so much for this, I've just given it a bit of a test and it worked great. I've commited it to 6.x-1.x. I think there are a few minor issues:
uc_event_registration.module:uc_event_registration_client_submit()
at the end you kept in the old attribute handling code (ie using$form_state['uc_event_attributes']
): is that for users in the middle of filling out a form when the module's updated? I wonder if that's necessary?Thanks again.
Comment #3
willowmedia CreditAttribution: willowmedia commentedSorry for not responding - I've only just noticed that you had commented on this issue! I'll try and find some time to work through your suggestions.. thanks.
Comment #4
AndyF CreditAttribution: AndyF commentedNo worries, anything you can get done would be great: the list is really there as a record, rather than a task list for yourself specifically! I'd be interested in hearing your thoughts on points 1 and 5 though...
Btw, in case you don't know you can set automatic emails for issues you follow (or all) on a particular project from Profile -> Notifications.
Thanks again
Comment #5
willowmedia CreditAttribution: willowmedia commentedWell I guess the current setup gives the site builder more flexibility/control over the product presentation but I think you are probably right we should be honouring the product attribute settings - although once we start going down that route I'm thinking we would have to write extra code to keep the two "models" in-sync. For example, when a product attribute is changed from non-mandatory to mandatory and it isn't already on the webform. Or for when a new attribute is added to a product and it is mandatory..
I've created a new patch so that the webform component description fields are pre-populated from the attribute's help text when
I'm not sure I entirely understand this one, I think my attribute components came out in the same order as the Product Attributes
I've created a new patch to display messages about ordering the attributes and changing their labels
Yes, you are right, the patch I produced did leave some redundant code behind - I think I left it there to make the patch smaller & easier to understand. There is probably also redundant code in uc_event_registration.module:uc_event_registration_form_alter()
I'll see if I can get time to clear out the old code.
The new patch I've just added was made against the 1.5 version - is that alright, or should I start rolling them against the 1.x-dev version now ?
Comment #6
willowmedia CreditAttribution: willowmedia commentedComment #7
AndyF CreditAttribution: AndyF commentedThanks again willowmedia.
Regarding patches, ideally they'd be against dev. Thanks for your work on this: I'm not going to be able to look at the patch until early next month, at which point I'll let you know.
Comment #8
AndyF CreditAttribution: AndyF commentedRegarding point 3, it turns out that I had some attributes that were equally weighted, in which case Ubercart uses their name for ordering. I've committed your patch and modified the update query to sort by attribute names after weight.
On further reflection I'm still a bit uncertain about point 1. A part of me feels that the most sensible way to handle things would be for every paidevent to necessarily have one and only one uc_attribute component for every attribute. Then the attribute can be configured to be hidden (allowing you to provide a default value). We can prevent people from adding/deleting uc_attribute components, but it still means we'll have to ensure the form remains up-to-date as product attributes change. The way that springs to mind is to check on node load if there are any invalid or missing attributes and dealing with them. A part of me balks at creating automatic behaviour like this that can be destructive however.
Any thoughts?
Comment #9
AndyF CreditAttribution: AndyF commentedRight this is done:
Thanks so much for your input.