Test/fix Views2 integration

Upon further testing, the stuff from duellj needed a lot of work, since that was before some of the final views API changes (e.g. hook_views_handlers(), etc). But, it was still a very good starting point. I've split all the handlers into separate .inc files, did some other fixes to make it work with the official views 6.x-2.1 release, and corrected #330961: Call to undefined function views_load_cache() (which I marked as duplicate with this issue).

Mostly this is working now, and folks are free to play with this and test it. The reasons I'm leaving it CNW are:

A) The 'signup_user_list' view from #243035: How to list all signed up users in a view?? isn't included here as a default view.

B) As a result of (A), I haven't really tested if the advanced setting to embed a view for the attendee list on signup nodes works at all.

C) The advanced setting to embed a view still hard-codes page and block display types from the views1 days. In the views2 world of multiple display types, we need to rethink this setting. Related to this, theme_signup_view_label() still is looking for $view->block etc, which no longer exists.

D) We don't take advantage of views2 relationships at all. Signup is a perfect candidate for exposing a relationship. I'm not yet sure if we should handle that as a followup issue, or if we should more fundamentally think the views2 support around the basis of a relationship before we commit all this.

@scottrigby: Please don't derail this issue with other feature requests. This is about getting the existing views support working in views2, nothing more. That said, please see:
#325493: Signup per time slots
#166619: expose form elements as views "fields"

New patch that renames the handlers to be in accordance with the suggested naming scheme for handlers. Still doesn't add relationship support, that's coming soon (and will really fix up a lot of the somewhat kludgy handlers in here now).

Oh, and yes, all the signup_handler*.inc files should go into the views/handlers directory. That directory now exists in CVS, there are just no files in there, so you might need a cvs up -d views before you apply the patch...

Yeah, I just renamed the files, classes, and references in signup_views_handlers(). I forgot to rename them in signup_views_data(), but that's an easy fix.

However, a few of these handlers are stupid (from the original views support, not because you did anything wrong converting to views2) now that views supports relationships. I've been getting some help from merlinofchaos on how to best handle these things, and will be posting a new patch sometime soon (hopefully tomorrow) that introduces relationships between nodes and users by means of the {signup_log} table. Once we have that, we can remove a few of these existing handlers and fix the default views to use the relationship, instead. That'll also make it a lot easier to implement the signup_user_list view I mentioned in 1.A above.

This fixes signup_views_data() for all the new class names, and includes the stub of a missing handler (signup_handler_field_signup_user_email). However, I still haven't actually had a chance to get the relationships working, and that needs to happen before any of this is committed, since it means the default views are going to need to be different, some of the handlers will need to be re-written, and some of the handlers won't be needed at all.

Getting closer.... ;)

- Adds a relationship in {signup_log} to the {users} table.
- Removes signup_handler_field_signup_user_username (which you can now get from the relationship).
- Removes signup_handler_argument_signup_user_uid (which you can mostly get from the relationship).
- Adds the signup_user_list default view, using the relationship.
- Fixes the signup_current_signups default view to use the relationship.
- Breaks the signup_available_signups default view by trying to use the relationship. ;)

While drinking the relationship koolaid, I thought we could completely get rid of signup_handler_argument_signup_user_uid. However, I asked merlinofchaos about it and he said the support in that argument for "nodes this user didn't signup for" is really tricky. So, it's possible we'll need to restore this custom argument handler after all, but I'm going to see if there's a better way still utilizing the relationship before we do it that.

Here's the updated TODO-list for this issue:

A) The 'signup_user_list' view isn't included here as a default view. Done.

B) Fix the code to embed a view for the signup user list on signup nodes. Fixed with patch #11.

C) Fix the UI so that you can select the display you want from the currently selected view, instead of the D5 page vs. block hard-coded stuff.

D) We don't take advantage of views2 relationships at all. Done.

E) Figure out how to build the signup_available_signups view, ideally using the "Signup: User" relationship, but perhaps by going back to our custom signup_handler_argument_signup_user_uid argument handler. Fixed by patch #20.

F) Add an argument validator plugin to filter on signup-enabled nodes (so that signup_user_list only appears on signup-enabled nodes). This is the D6 way to do this, instead of the D5 hook_views_url_tokens() that exposed a "$signup" url token. Fixed by patch #12.

G) Implement signup_handler_field_signup_user_email such that if it's an authenticated signup, we grab the {users}.mail field from the relationship and if it's anonymous, we grab {signup_log}.anon_mail directly from our table. Fixed by patch #13 (I think). ;)

(B) is now fixed. (C) is a little tricky, since it seems like the best thing would be to use a little AJAX to figure out what display ids are available based on the currently selected view. Not sure I want to get that complicated. For now, it works with 'page' and 'block' displays, which should probably cover 98% of all use-cases, anyway.

Fixes (F) by adding a "Signup status" argument validator plugin, and adds that to the signup_user_list view. Also fixes a syntax error in signup.install from the previous patch. ;)

This seems to be the right way to fix (G). I'm including the signup_handler_field_signup_user_email.inc file as a separate attachment, too, to hopefully make it easier to get views2 experts to confirm. ;)

Rerolled after #328840: Rename the email tokens, especially %event and %eventurl

do you have a singup/views/plugins directory with a .inc file in it after you apply the patch?

After feedback from merlinofchaos via IRC, improved signup_handler_field_signup_user_email.inc quite a bit.

NOTE to reviewers: To apply this patch, you need to checkout a fresh copy of signup from HEAD, run cvs up -d to make sure you have the views/handlers and views/plugins directories, then from the root of the signup directory, run patch -p0 < 330820_signup_views2_port.18.patch.

This fixes (E), the signup_available_signups view. merlinofchaos thinks that a custom argument handler is really the only way to get this working (like we had up until patch #10). So, this fixes up signup_handler_argument_signup_user_uid.inc a bit, changes the signup_available_signups view to use this argument handler and not the {signup_log} -> {users} relationship, and otherwise gets the view working properly again.

I'm a little worried that this argument handler completely breaks if you add the {signup_log} -> {users} relationship on a view that uses it, since that adds an INNER JOIN on {users}, and that breaks the LEFT JOIN logic the handler is doing. Not sure what to do about that part. Also, the UI is a little confusing -- perhaps this handler shouldn't be general, and should be named specifically as the "filters nodes the given user id has not signed up for" argument handler, and then do away with the checkbox. Not sure about that, either. ;)

Once these questions are resolved, the only thing that remains from the known problems is (C) -- how to select the right display name for the view you want to embed for the user listing. merlin's suggestion there was to just have a single selector with "name - display_name" options. Makes for a bigger list, but much easier than trying to split it out into two settings.

This fixes up some of the problems with signup_handler_argument_signup_user_uid.inc, although things are still a little broken if you add the {signup_log} -> {users} relationship. That relationship really doesn't make sense for views trying to use this argument, so I think it's fine. I also changed it to use a pseudo field definition in signup_views_data() so that I had more control over how this argument appears in the UI, and did in fact hard-code it to be the "nodes you haven't signed up for" argument, instead of trying to be a generic one that can handle either.

Woo hoo, this solves all known issues. ;) (C) is now solved as per merlin's suggestion which I described in #19. Definitely makes for a slightly unwieldy drop-down list, but otherwise, it works great. Sites can always implement their own version of theme_signup_view_label() if they want to remove the descriptions, etc.

Decided to commit this to HEAD, since it all seems to work for me. However, more testing is definitely welcome. If anyone else runs into any problems, please open new issues about them. Thanks!

Note: the previous version of this was broken if you tried to embed a block view as the signup user list. The problem was that I was using $view->execute_display(). merlinofchaos tells me that returns output suitable for the display's context, and in the case of block displays, that means an array suitable for hook_block(). If we just want the rendered HTML for the display, we need to use $view->preview(). Slightly counter-intuitive, but it works. Committed to HEAD.

FYI: related bugs/problems:
#336442: Views2 filters for signup disabled/enabled and 'send confirmation' broken by cut+paste error
#336450: Signup's views2 boolean filters have terrible UI
#336461: Incorrect filter handler for "Signup: Reminder: Enabled/Disabled"

Just noticed one other minor problem with the initial Views2 support -- we no longer need to conditionally load anything in signup_init() since Views does that automatically thanks to hook_views_api(). Committed to HEAD and DRUPAL-6--1:
http://drupal.org/cvs?commit=163084
http://drupal.org/cvs?commit=163085