ldweeks [ldweeks]

CVS edit link for ldweeks

My name is Lucas Weeks, and I've been involved with Drupal for just under 2 years.

This module exists to give site-builders the ability to sell ubercart products from within a webform. They are not limited as to the type of product that they include in a webform (although, I have not yet added support for attributes and options), but this module can easily be used to create a registration system.

I was inspired to write this module after I built a hacked-together registration system for a client using the webform module and ubercart. Initially, I followed instructions (with some tweaking of my own) that I found here:

http://openconcept.ca/blog/ethan/ubercart_event_registration

I since came across this post, providing yet another way to create a registration system with ubercart:

http://drupaleasy.com/blogs/ultimike/2009/03/event-registration-ubercart

Both of those posts are now over a year old, and since then, quicksketch has released the 3.x branch of the webform module. The most important new feature, from my perspective, was the addition of an API that allows integrators to create their own, custom components. At that point, I figured that I'd write my own module so that I wouldn't have to go through the hassle of writing custom code each time we needed a new registration form.

The concern about duplicating existing work will naturally come up at this point, since my module is yet another solution to the problem of how to handle online registration. The projects signup and uc_signup both already exist, so why add my module to the list?

I certainly need to justify why I chose not to create patches for the uc_signup module, but do keep in mind that my module doesn't have to be used as a registration system. In other words, it has broader application than simply a registration system, and those other uses may alone justify its existance. It simply allows site creators to embed products within their webform, and sell those products directly after the form is submitted. Period. That aside, however, what follows is my defense of why my module is unique and beneficial to the community at large.

First, here are a few modules that I found that try to solve *similar* problems (I'm not aware of others, but it's likely that there are a few others out there):
- http://drupal.org/project/signup
- http://drupal.org/project/uc_signup
- http://drupal.org/project/cck_signup
- Joachim's fork of the signup module that is currently on github: http://github.com/joachim-n/signup

Here are a few links to discussions about this topic, most of which are in the issue queues of the above modules:
- http://drupal.org/node/29568 - Really loooong thread in which Joachim provides a patch for the signup module, and then begins fielding support questions.
- http://drupal.org/node/623900 (duplicate found here: http://drupal.org/node/527700) - Discussion with ezra-g about adding support for collecting other information from other modules from the uc_signup side of things.
- http://drupal.org/node/29568 - Discussion of adding flexible fields in signup module.

In one of the threads, Joachim mentions that he and dww were supposed to talk things over at Drupal Con Copenhagen, but I don't know what ever became of that.

With that information as a background, I will admit that I have not contacted any of these module maintainers about my work. Even if we focus solely on the registration aspect of my module, I'm convinced that the base assumptions that I make about how a site-builders want to build registrations is different enough to warrent a separate module. The signup module, for instance, assumes that each attendee will have an account on the website (see the signup and uc_signup project pages). My module makes no such assumption. The signup module (and therefore the uc_signup module as well) requires that every distinct registration form is also a distinct content type. A site that handles many registrations will end up with an increasingly large number of content types. Again, my module has no such requirement: if you need a new registration form, you simply create a new webform node.

Finally, and I think that this is the real kicker, there is a fundamental dependency within the signup and uc_signup modules on the core profile module. All the "extra" information about signing up for an event would go into the core profile module. That is not a viable solution for a site that wants to offer registration for many different events. To handle that, as far as I know, I'd have to continually be editing the profile fields on my site, presumably deleting old info whenever I create a new registration form.

Admittedly, this is precisely the problem that Joachim (and perhaps others?) are working on in Joachim's fork of the signup module on github. However, fundamental limitations remain in the signup module even *if* you can collect data with other modules (like not being able to purchase multiple products when you fill out the registration form, for instance).

So, ultimately, I'm convinced that we're coming at the problem of registration from two fundamentally different perspectives, and that my module would be a benefit to the drupal ecosystem.

My code is over on github: http://github.com/ldweeks/uc_webform. I have done my best to follow drupal coding standards and security best practices. This is my first full-fledged module, though, so I'm sure that I've made mistakes. Thanks for taking the time to review my submission!