Views integration

Thanks, catch.

So I'm trying to set up a simple jump view and am having some trouble getting going. I'm only getting one item in the jump menu and am also not sure what to do about how to set up the fields to get the options keys so that hitting "Go" sends the user where they expect to go.

My view selects all nodes and sorts by Title. I'm choosing Node: title and Node: link as the fields to display. I really want to see just the title of each node in the jump menu and then I want to go to the node whose title is selected when I hit Go. How do I configure the view to do this?

This is how I've been doing it:

Add a field for node title as you've done.

Add a field for node id.

In the node id settings, set that to 'rewrite the content of this field' so it outputs as node/[nid]. Also set it to not be rendered.

In the settings for the 'jump menu' style, select the 'nid' checkbox in the options to build the select keys.

Then your select $options looks like:

This is a really nice feature. I will be working on integrating this into the development version of jump.

The following patch integrates this feature into the jump module.

I think drupal 6 automatically deals with multiple forms with the same ID appearing on a page, but not 100% sure of that. It'd also be possible to keep this in jump.module without an explicit views dependency fwiw. Thanks for rolling into a patch and adding the default view by the way.

@evoltech - Thanks for getting the patch process going! A couple things to change in the next one:

1. Like catch said, we shouldn't need the dependency in the .info file (please test to make sure)
2. Instead of pulling out the get_num_jump_forms() function so that it can get called in jump_views_plugin_style.inc, I'd prefer that the code in jump_views_plugin_style.inc call jump_quickly() which returns a form. That'll keep everything going through 1 channel.

After those couple changes get in there, I'd like to test this out and get it in.

I'm also not sure about the multiple forms with the same ID in D6, but since it's all working correctly now I'd rather just keep that in there and not mess with it on this patch. We can do more research on that and raise a separate issue later on.

@either evoltech or catch - there's a comment in jump_views_plugin_style::get_render_tokens() that says it's slightly modified from views_handler_field.inc -- what's going on with those array_flip() calls?

array_flip() is because sometimes you need to lookup aliases via fields, and sometimes fields via aliases - and array_flip() + isset() is faster than something like array_search(). The code is based on views_handler_field.inc but by the time it was working quite different, so we really have to do our own implementation there - a lot less verbose than the alternatives.

I tested and verified there was no need to create a dependency on views in the .info.

Re-rolled as per @marcp's requests in #6.

@evoltech - thanks for the re-roll.

It's pretty close now -- I've got a couple changes in addition to the patch, but there's one last thing that's bugging me. If there's an apostrophe in the node title (in our example where we just choose node title and nid), it gets blasted out as ' because we're sending the fully rendered row into the select box.

Anyone have an easy solution for this?

Okay, I've got this checked in with some minor modifications. I fixed the apostrophe thing similar to how it's done in #320139: Reversal of Views check_plain() call should include ENT_QUOTES.

Switched around the sorting for the default view (nice idea to provide that, evoltech) and added a filter on Node: published or admin.

I'd like to get some documentation in place for this and maybe have one or more folks test this out before cutting a release. Folks have been asking for this for a long time -- thanks, you guys.

Awesome.

One thing I forgot to mention and couldn't quite decide on is whether to continue allow multiple fields for the select keys, or just change that to a radio instead on the assumption everyone is going to pick one field and rewrite it. Would be a small change, but if you think a radio might work better, would probably need to be changed before cutting a tag.

I think the radio would be a lot better, so that'll need to get in there before this gets released. Only having to configure the tokens for one field will make the thing a little easier to understand.

Ideally, the user wouldn't have to configure anything other than selecting "Jump menu" for the view style. If it's a node view, the default would be node/[nid]. If it's a user view the default would be user/[uid]. We'll still want the token substitution flexibility in there to make it easy to create user/[uid]/track or group/[nid]/blog-posts (or whatever), but the default should just work without any monkeying around with the settings.

Any thoughts on how easy that would be? I don't have enough of a handle on views to know whether there's a generic something/ID path for every view type out there. Seems like there's got to be a view type-specific ID for every row (nid for node, uid for user, vid? for node_revision?, etc).

The very last line in the Views 6.x-2.7 Release Notes says "# If you have CTools 1.3 enabled, you can use a "Jump Menu" style for both summaries and normal Views."

Anyone able to confirm that? Is their implementation better than what we're heading towards here? Comments?

Also wondered, too. Opened #622740: Please document "jump menu".

I've just seen that come up too. Spoke to merlin briefly and he'd worked on it parallel to this patch so there's no relationship between the code - am going to try that out today though and see what the difference is. However statistically anything merlin does is likely to be better than mine ;)

@marcp, the following patch is in response to #12. It was created against the most recent jump-DRUPAL-6--1 branch. I re-opened #622740: Please document "jump menu", because I could not see this style in the views UI either, and have no ideal how to use it.

I think the Views/ChaosTools thing is going to be the way to go, but I haven't yet gotten it working because ctools is only on 6.x-1.2 and Views needs it to be on 1.3 in order for the Jump menu plugin to work.

If anyone wants to try to get it going, install Views 6.x-2.7 and the latest Dev version of Chaos Tools. Make sure that the Chaos Tools returns 1.3 for the api_version (you may need to hack the module). I suspect it will work.

Looking at the code makes me believe that it makes you pick 1 field for the "destination" which is cleaner than what we've got now. I'm not sure if it allows rewrites on there, but I suspect it does. If it does, then I think we shouldn't bother including this in Jump.

Anyone available to try it out?

Note also that the view style title in chaos tools is "Jump menu" just like the one in Jump, so be sure to get rid of the Jump views includes before trying the ctools one...