I maintain the signup.module. This module has long struggled with the problem of how to flexibly define what fields are requested and/or required when a user signs up for something. I might have a slick solution, but I'm not sure if CCK can accomplish what I have in mind.
With 5.x CCK, you can assign any fields you want in whatever groups you need to any node type. My module could allow site admins to define the signup/reply form for any given node type as a specific group of arbitrary CCK fields. This field group would not show up on the node edit form. It would be displayed on the node view page itself, so each user could fill-in, submit, and optionally edit their own signup/reply. All fields would automatically be treated as "multiples" in terms of storage, 1 set of each field's values per user who replies, but displayed as single values for any given user viewing the node. When a user replies, the values of any fields in their reply would have to be associated with their identity (uid for auth users, email for anon).
I'm not sure if my module would have to manage its own separate field data tables for this, so it could add an extra id column to each field. I don't know anything about the internals of CCK to know how much of the API I could re-use, and how much of this would have to be custom. For example, if the field's data is stored as multiples, but the field form always wants to show them as singles, is there any code in CCK I can use or will this require tons of my own effort? I'm expecting that with form_alter() and module weight, I can make sure this fieldset is totally gone on the node edit page, and via nodeapi, I can inject my form into node view (that's how signup.module works already).
Previously, I considered just defining an "event reply" CCK node type, with a node reference, a user reference, and whatever reply fields you wanted. Then, you just create a reply node when you want to reply/sign-up for something. Con: that would generate a ton of nodes, especially on large sites with lots of users doing lots of events. Pro: I'd get to track revisions (and diffs) of the replies for free that way, and perhaps a lot of other things would all Just Work*. But maybe (mis)using the CCK field multiples concept and mapping sets of values to each user is better, and leaving all of it as data stored with a given event node.
I'm just about to start a round of major new development to add a bunch of the features I've been using on my own site (http://BateriaLucha.org) and make them more generic and flexible. I'm thinking of renaming the module to the "reply.module", since one of the features will be tracking people who reply that they can not attend an event, so "signup" doesn't really make as much sense anymore. This would be the perfect time to do this CCK-ification, I'm just trying to figure out how feasable it would be from a CCK + Views perspective.
If all the reply data is stored as CCK fields (and the info about how a given node is configured for replies is views-enabled), it seems like it'd be trivial to define default views that showed: various levels of detail about all the users who replied to a given node, summary listings of many nodes, views of all the reply-enabled nodes on the site that you have not yet replied to, and grid views like I have on my site:
However, I'm not much of a Views maestro yet, and I have no idea if my schemes for (ab)using CCK would work. ;) Any insights, pointers, offers for collaboration, and/or help (sponsorship or code) would be most appreciated.
Thanks!
-Derek
Comments
Also for Survey module
This same thought had occurred to us in looking at http://drupal.org/project/survey module. James did a quick port to Drupal 5, and was thinking of embarking on this path for a 2.x branch: make CCK fields instead of the custom form items from the forms module.
The big discussion point is survey responses as nodes or not. Ideally, just get the CCK field widgets but then store the responses just in the database.
This feels like it should be doable. Maybe use the http://drupal.org/project/forms module as the glue between CCK fields and forms creation?
You can do some very
You can do some very creative things with CCK. As an example, look at the pollfield module which turns a multiple value field into a poll that displays the user survey form on the node view and the admin setup form in the node edit form. That module is very new and needs work (and it also joins in some external tables which makes it more confusing to understand), but it might give you some ideas and it illustrates that you can be creative with the form handling.
Basically, if you make a CCK field multiple value, it will have its own table. Define a column in the field for each item you need to track and you have your table creation and maintenance for free.
This is above and beyond the built-in Views handling capabilities of CCK, though, which will only expose your first (main) column to Views, but you can add custom Views handling to expose your other fields so you can create tables like the ones you want in Views. The pollfield module has to do custom Views handling to make all its fields available to Views, so you can see how it does that.
Once all your field columns are exposed to Views, you can do creative stuff with displaying views in nodes using Viewfield or some templating.
I keep promising to do more things than I possibly have time to do, but I'd love to see this and would be glad to try to help or at least provide feedback and ideas.
Question on non-node usage of CCK fields
From my original comment and some thinking I had been doing, I was thinking about if it is possible to use CCK fields without joining them on a node.
So, consider:
Create a new survey (which is a node). Select the fields you would like to include (which are CCK field types).
Now, users come and fill out the survey. Instead of creating a new node, it goes into (some sort of survey module database table(s) that can link to the CCK field values).
Possible? Crazy?
I have been trying to think
I have been trying to think of a way to do this, too, but haven't come up with one. If we could extract widgets out into a library allow them to be used in various ways by various modules instead of only on CCK nodes, it would be very powerful, and that would be one more step on the path to pushing CCK into core.
how is this different from what i just described?
maybe i wasn't clear enough in my original post, but this sounds exactly like what i'm talking about:
the admin defines your "survey" as CCK fields on some special "survey" node type (or in my case, "signup" fields on an "event"). users come to the node to fill out the questions (survey, signup, whatever). instead of creating a new node, the replies go into CCK multiple-storage fields on the parent node, and you just have to tie each set of fields in a reply to the user who filled out the "survey".
so, each "survey" node can have its own title, description, etc (any fields outside of the "reply" fieldgroup that gets the special treatment), but all the same reply fields. if you want different kinds of questions, you just make different survey node types (in my case: different event node types that have different reply fields for different kinds of events, if you actually need that).
was i not clear, or am i missing something about what's different about this question?
thanks,
-derek
CCK multiple-storage fields needed
If you read KarenS's answer (I think), it still deals with all data in CCK fields being associated with different nodes. So, the default (and not hard) way of doing this is that each survey submission in fact creates a node in the background -- rather than what you or I need, which is one node, with multiple CCK data values stored along with session/user/something (need to support anonymous submission of surveys and signups).
So, we're in (vehement!) agreement on what we need, but I don't think we have a clear way to do it.
This being exactly what we need:
Actually, what I was
Actually, what I was thinking of for the signup example is that you would put one multiple value signup field on the event node and then each individual response becomes an entry in the field table associated with that node, so one node for each event, not one node for each signup. The survey example would be to create one node for each distinct survey, and each user's response to that survey becoming an entry in the field table for that node. Again, one node for all. This is the way the pollfield module works.
The weakness in the system for surveys is that you may (probably will) want each individual survey to have completely different fields, which as things currently stand would mean you would need to create a new content type so you can give each survey different fields and widgets, so that's the problem I haven't found a solution for.
That is not so much of a problem for event signups because you don't need every signup form to be different, for the most part you're storing the same or similar data for each signup, so you could get away with one signup field type and attach it to all your events, or maybe a couple different signup fields if you need to collect different info for some kinds of events.
I'm probably not explaining this very well, but I think this will work for signups, but may not work so well for surveys.
Great
No, that absolutely makes sense.
While it would make the content types page "messy" for many different types of surveys....I actually don't think it's such a huge deal. Maybe survey module could form alter the content types listing to review ones that are "owned" by survey, and display them separately.
terrific approach
i agree that this is promising. thanks for the direction ...
yay!
the cavalry has arrived. ;) if it's reasonably possible to do what i'm talking about using CCK (and i don't mind having to do a little extra work to expose this insanity to views), and if walkah is working on similar stuff where we could coordinate and share effort, and if the queen of CCK is willing to provide help/feedback/ideas, i think this could really happen. ;) i guess we'll have to see what walkah has to say about all this... meanwhile, i'll take a look at pollfield for some lower-level ideas on how to accomplish it. thanks, Karen!
CRM API
Taking this a little bit further, please forgive me for going a little past the original intent for this node.
Something we are working on right now here at Trellon, that might be useful for this kind of thing in the future, is a CRM API. Basically, there are a lot of modules that need a centralized means of storing data submitted by users, both in Drupal using distinct content types and external systems (such as Raiser's Edge, Salesforce.com, NGP, CiviCRM, SugarCRM, etc). On the other side, that information often needs to be visible to other audiences with specific needs, i.e. the fundraising unit has different data needs than the people engaged in activism. While a lot of this can be accomplished through views, there are some situations where additional data collection is necessary, as in activity records in CiviCRM.
Having a single method to determine the means of storage for data collected and a convienent means of drawing information out of an external system becomes more important, especially in the case of events, as there are often a lot of ways people want to understand this data. For instance, an event host is going to want to know who is signed up for an event, a regional organizer may want to know which areas have the highest event turnout, and a fundraiser might want to know who the people are that participate in the most events.
Even if you are strictly using CCK nodes to store signup information, there is a problem that comes with having to integrate external modules into a solution. Let's say someone wants to tie webform submissions to event registration. You could write a custom module that adds a hidden field to a specific form, a hook into views for retrieving this data, and a special page for viewing it. That's a lot of code. It would be better to have something that can automatically target forms to create a tracking code specific to the means of storage being used, using a Web based interface similar to that of views, that would let relative n00bs tie this information together without the need for extensive programming.
That's what this CRM API is all about, finding a way to integrate all the different modules that have their own specific means of storage into a system that can a) collect information in Drupal or any external system for which there is a plug in and b) automate some specific data collection activities in order to tie disparate pieces of information together without the need for writing special handlers for other modules.
We're getting ready to deploy an early version on a couple sites tying CiviCRM and NGP tools together and using views to handle specific display requirements.
M
Cross-table view
Investigate the new cross-table bonus view to display the view. Not completely working yet, but looks promising... The patch is at http://drupal.org/node/121730, the original post about it with an illustration is at http://groups.drupal.org/node/2879.
interesting..
a really interesting discussion.. but what's so bad with signups as nodes? It seems that it would solve all problems, so why not?
ad: If you think of trying this way, have a look at my subform element module, which allows you to reuse the node form easily on node view..
Too many nodes
You would have one signup node for every single person that signs up. Which means 100s or 1000s of nodes per event. Plus having to "hide" and control access to all these nodes. Plus keeping a relationship between the signup node and all the signups.
And yes, subform is excellent :P
groups.drupal.org will use this
if we can come up with a cck powered signup, i would definately use that on this site. i also plan to use karen's module for converting from event nodes to cck date fields.
any progress?
Hi,
This is what's holding me back from migrating an orchestra web site to Drupal. We currently have a calendar with events, i.e. rehearsals, that orchestra members, i.e. web site users, can "opt out" from. The default is that you are required to participate in all rehearsals, but if you need to be away from one rehearsal, you log in to the website, go to the calendar, and opt out from the rehearsal by either choosing the option "Absent" or "Late arrival". In the latter case you also give the estimated time of arrival. The data is stored in a table with the fields user_id, event_id, status (i.e. absent or late) and E.T.A. When the data is saved, an e-mail is sent to those who need to know that someone has opted out from the rehearsal. If a user updates the information, the row in the table for the particular user_id/event_id combination is either updated with the new information, or deleted (the default is that all users participates in all rehearsals). It is possible for certain user roles to view a table with all the opt out information organised per event or per user, i.e. either a table for one event with a row for each user, and their status, or a table for one user and one row for each event with the particular user's status.
I've been trying to figure out how to implement this without having to write a new module. This is the only functionality that I need before migrating the whole site to Drupal, and it seems that it's very related to the functionality dww describes in the initial post. So, are there any news or any progress towards this functionality?
Cheers,
T
no progress until after the D6 API/feature freeze
all my drupal time in the next ~10 days is focused on core development in anticipation of the D6 freeze... after that, i'll return to all of this at some point.
Revisitation?
Is this going to be put back on the table for development?
This solution is farther that we have gotten on the same problem.
We are interested in helping if there is a solution to this problem.
this still seems to be a
this still seems to be a viable issue right?? Even after 1.5yrs from the original post.
Now...what about the Webform module that is new (newer than this post anyways)? Can a webform be created (called "registration form") and then from the signup admin reference (using nodereference module) that webform. The registration form would then be a link from the event node page.
You could then have multiple 'default' registration (web)forms for event node owners to choose from and restrict the nodereference content type to only allow webforms to be referenced.
The other tricks would be to allow the event node owner to customize what the "register now" button/link (to the referenced webform) would read and for when you follow the link to the registration (web)form to then reverse reference the event that you just came from so the webform would be linked to that event.
Just an idea...
...or just emded the interface/abilities of webform into the event signup admin settings...
Then of course, how do you get to use this webform info in all the cool Signup tools that are now available (download registrants, email certain roles, change registrant status (with emails sent)).