Views form element to select nodes

Subscribing - no time to test right now, but this sounds :
- really interesting
- badly needed

Similar projects:
- http://drupal.org/project/editview
- http://drupal.org/project/subform

Since it looks like there is strong demand for this kind of functionality we should try to join efforts ...

susbscribing --

will test over the weekend --

Very nice. I can see lots of uses for this, Subscribing.

I'm keeping an eye on this, but at this time I don't have the time to be involved in active testing/development, so definitely getting a few people together who have an interest to help out with this is a good idea.

It's very interesting.

I tested this out and it is excellent. I have no idea how to implement it the way I want, but I very much look forward to when it is integrated. Specifically, I want this feature with nodereference. When my user goes to create a node and can see in front of them all of their choices, it is much more intuitive than trying to find it in a dropdown. Thanks for doing this and I look forward to actually using it. How difficult would it be to put this into nodereference.module now?

+1 for this feature.

Node reference does not allow for ease of finding the proper node. Especially when the nodes are similarly named. Being able to see more information about the nodes you are choosing will be great!

I was directed here from my original feature request. Sounds very good. I presume it can't be tested against Drupal 5.x yet?

Drupal 5.0-RC-1
GD library 2.0 or higher
MySQL database 5.0.24a
PHP 5.1.6
Unicode library PHP Mbstring Extension
Web server Apache/2.0.55 (Ubuntu) PHP/5.1.6
Views 5.x-1.4-2rc1.

Here's what happens:

- Created folder called viewselector in: sites/all/modules.
- Placed viewselector.module and viewselector.inc in folder.
- Created extra file: viewselector.info, (basically copied contents from views_bonus.info)
- Enabled module
- Clicked on newly created menu entry in Navigation: "testing view selector"

Result is white page with:
Fatal error: Call to undefined function _views_get_default_views() in /var/www/parallelports/sites/all/modules/viewselector/viewselector.module on line 435

Next:
- Truncated cache table with PhpMyadmin
- Clicked on "testing view selector"

Result:
warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'viewselector_test_form' was given in /var/www/parallelports/includes/form.inc on line 217.

Next:
- Added following line before $default_views = _views_get_default_views(); in viewselector.module:
views_load_cache();

Result:
Same error message as above.

Hope this means something to you, it's all Chinese to me!
Ciao

Any progress here? Since Views is now 5.0 compatible, we will probably need that verison before commit.

Changing version.

I actually have this running in Drupal 5.1 in combination with the noderefselector module. Only problem is that the filter is not working on the node edit form. It can decide which items have been selected, but it won't filter based on the exposed filter of the view. Any ideas why? - right now I'm stuck with either one big list of nodes to select from, or only the nodes that have already been selected - no inbetween.

Any progress here?

Is there a newer version than Dec. 13th? - subscribing

Thanks for the info

I've tried the viewselector test page on a few views and like the way it works.

How do I use this module in different scenarios such as:

--table view of 25 items, I want to select a few and display only those items
--you mentioned cck with node reference to display select box as check boxes or radio buttons

I have limited exposure to drupal modules but am ok with some programming and themeing

subscribe - sounds very useful - will test when I get time ...

Mark, I want to try to do some reviewing but am completely confused about what I need to do to see this in action so I can. Sorry if I'm being dense, but this thread is long and confusing. If I am starting with a clean 5.x install of Drupal and Views, what exactly do I need to do to get to the point where I have something I can review? Is it just apply the patch at http://drupal.org/node/125973 to Views and get the module from your sandbox??

BTW, the subform module mentioned earlier seems to have been abandoned by its maintainer, so that module is clearly not a viable alternative (lots of 'where is MrTaco?' questions and comments from people who tried and failed to find a way to clean up the code in the issues queue, plus just try to find out more about him from the link on his Drupal user page you'll find not only is it not a Drupal site but there is not even a home page!).

+1 on this idea from me, and I think this is very close to working as it should. Nice job Mark!

I've tried out the patch and the views selector and nodereference selector modules, so here's my assessment:

1) I had problems applying the patch, noted in the patch issue. Once I got past that, the patch works fine and adds a nice new capability to pass filters as well as args to views_build_view(), which is a very nice feature irregardless of anything done here.

2) On the Views Selector, your "testing view selector" menu item is visible to anonymous users. I would move that into the admin area and give it some access control. Or maybe it's going away and is not meant to be a part of the final module, wasn't sure about that. I found it a bit confusing to understand, but again, I'm not sure if that is going to stay or not, so I'm not going to worry about that for now.

3) I did some playing around with the Views selector, but wouldn't say I have fully tested it yet. Initially things seem to be working fine.

4) As to the nodereference selector, nice feature! and basically it works fine, but there are a few issues. For one thing, you need to select the same view in the field as you select in the widget or you can run into problems when your widget allows you to select items that the field doesn't allow, so that needs to be documented in the widget settings. There are some other issues/fixes I could suggest, but I'm not sure I should pollute this issue by going into that here. I should get them documented somewhere while they are fresh in my mind, though, so maybe we should open a CCK issue for that??

I think this is what I have been looking for, but I am not quite sure at this point.

I have set up a clean install of Drupal 5.x, uploaded the patched Views module, view selector files, devel and CCK. I created a single CCK field added to the page node type and then created a test view showing the title and the cck field that I created.

I pulled up testing view selector, selected test as the view and left all of the other fields blank, hit submit and I get a list of node teasers (clearly not what was called for in the test view). It is not clear viewselector is at work here. I am not seeing where the selected subfields are showing. I seem to be missing something here, but not sure what. Any guidance you can provide would be greatly appreciated.

BTW - had the same problems with the first chunk when trying to patch views.module. Used KarenS' suggestion and just deleted the 1st chunk from the patch, then all went fine. After that, install was flawless.

Thanks - jarea

@jarea, yes, sounds like you are still missing something in your installation. When you see the view in the node it should be in a table format with checkboxes next to each title. You had to install the Node Reference Views Widget (in the CCK area) and the Views Form Element (in the Views area).

Once installed, when you go to edit your nodereference field, you'll see two places that refer to Views. The one at the bottom of the page is created by the core nodereference module and is not the one you want to work with here. You want the one at the top of the page. If you select the test view in that one and save the field, you should see the view in your node as a table with checkboxes. Note that you need to select the same view in the view selector at the bottom of the page for this to work, as I mentioned in my post above.

I've attached a screenshot of the field settings page.

And here is what the create content page looks like with the nodereference field I just created...

KarenS - thanks for the pointers. I didn't have nodereference activated. Works now as illustrated (thanks for the png too)

jarea

+1 This is awesome Mark! I had one issue when filtering, and I had not put in a title yet for the node, after clicking to filter the filter worked, but the validation was triggered, highlighting the title in red and explaining I must enter a title. I may need to update my install. This is really great!

On the nodereference selector, I don't think the widget should control the field's allowed values, that's the opposite of the CCK way of doing things. The field needs to control things, so I would have the widget just use whatever view the field has selected. Don't know what you do if the field has not selected a view, and has instead checked specific content types, so somehow we need to force the field to make a selection of a view (which again is not good CCK procedure since the widget should not behave that way). So after rambling around, I think the widget must use the field's view selection, but I'm not quite sure of the 'right' way to force the field to use a view.

I ran into another problem on the nodereference selector. If the view has filters and the base view filters one way and you change the filters at runtime to filter something different, you end up with problems because the 'allowed' values are different than what is selected. I'm not quite sure how best to fix this. Test the issue by creating a view with a filter like content type that has one content type selected in the view itself and the filter exposed. As soon as you change the exposed filter to any other content type you have problems.

Sub

Any further news on that form element? I am getting itchy to implement http://drupal.org/node/125810 but i'd just as soon piggy back on your work as much as possible.

Also, I read through the code and noticed:
- "Here we create a fake column for use in views.". Views recently got an alter hook hook when building the tables array so you often don't need to fake a column anymore. Just add the item to the existing table.
- you use dprint_r(). thats old school. We now abbreviate to dpr(). Also enjoy its friends, dsm() and dvm().

I need this for a project and will be taking what is available and working on it as necessary. Can you confirm that the sandbox version of two weeks ago should work with the DRUPAL-5 and HEAD versions of views?

Thanks for this great module.

Subscribing.

mfredrickson, I've been following your efforts on this with much interest from day one, but only took the actual time to test it a few weeks ago (shame), and fell immediately in love with it. This is an invaluable addition, which opens the door to a lot of cool UIs.

I'll make sure to help testing and reviewing this new patch as soon as time permits (close deadline on my side right now). Meanwhile, I just waited to voice my praise :-)

subscribe

subscribe

Hi Mark,

I used your great patch to implement "bulk node operations", a feature that was also envisioned by Moshe a while back. You can find the thread here. I had to make a small change to your patch to enable the "select all" functionality present today in admin/content/node among others. Here's what I did:

In file views_form.inc, replace the line 295 that says

array_unshift($view->table_header, array('data' => '', 'class' => 'view-cell-header'));

with

array_unshift($view->table_header, theme('table_select_header_cell'));

It would be great if you could incorporate that modification in your patch.

Thanks,
Karim

Subscribing...

Mark: I'd like to encourage you to get this patch to the point where I should be reviewing it. (I've been letting you guys work on it while it's in CNW status).

Second: Everyone should take a look at http://drupal.org/node/103171 -- this does something interesting. The patch that's currently there needs a lot of work, I think, but the basic approach looks like a decent idea. I'm afraid, however, that this approach and that approach may end up at odds, and I absolutely don't want that. I would like people to work together to make sure that both efforts can be used.

Getting Views to reasonably do forms is going to be a big deal.

Oops. That patch is at http://drupal.org/node/151868 -- sorry about that.

I'm leery about actually storing filter values. Why do we need to store them?

I've completed the implementation of a sub-module called views_actions that uses the Views form element to allow selecting multiple nodes from a view and applying an action on the selection. It is currently available at http://groups.drupal.org/node/4725. Ideally, this code could be merged with Views Bonus Pack for example, but right now it completely relies on the form element patch and so its fate is bound to that of the patch.

Since the functionality offered by views_actions complements what's offered here, I'd appreciate that the people on this thread take a look at it and give me some feedback. Specifically, I'd appreciate hearing from mfredrickson and merlinofchaos to critique my approach and help me find the right packaging for the code.

FYI: I applied the Views form element patch to Views 4.7.x-1.6-beta5, it worked well as far as I could tell.

Note that individual filters can, if they like, serialize their data themselves. There's a method to do this in the API docs, in fact, though it is a bit of a pain.

I can see adding value-type: serialized and doing an automatic serialize/unserialize on save if this is true; I think that would be better than automatically serializing all values. It's true, it's not normalized but in general other processes shouldn't be poking at these database values. And that'd be less intrusive than updating everyone's views databases.

Patch against views DRUPAL-5--1-6

New version of views_form.inc that includes this patch: http://groups.drupal.org/files/views_actions.patch_.txt.

Required to run "Views Bulk Operations" http://drupal.org/project/views_bulk_operations - which is broken ATM :)

Let's start by adding some documentation to this patch. Let's get an @file which gives a rough idea of what we do. Also, let's put the functions most likely to tell you what the file does at the top; the first function in there is a private function. Not so good for getting a feel for what it does.

subscribing

The views_bulk_operations module is indeed functional. Download the dev version here: Views Bulk Operations Module.

To get a working version yourself, you'll need to do the following:

0) Install Drupal 5.1 and views (DRUPAL-5--1-6); also install workflow and actions module for best demo (optional).

1) apply the patch in comment#56 to views DRUPAL-5--1-6

2) save the file in comment#57 to modules/views/views_form.inc

Gratuitous screenshot attached for marketing purposes.

Help testing appreciated.

Latest views_form.inc

Cleaned up and better documented.

Changing version value. The latest patch and views_form.inc file apply against views DRUPAL-5--1-6

First, I don't suppose you can convince your editor not to trim whitespace? I realize it's a flaw in MY editor that leaves the whitespace there invisibly, but it makes the patch a little more difficult. Only a little, so it's not a HUGE deal.

+// Definitions
+define(VIEWS_FORM_DEFAULT_VIEW, 'frontpage');
+

and

+  $type['views_node_selector'] = array(
+    '#input' => TRUE,
+    '#process' => array('views_form_process_element' => array()),
+    '#view' => VIEWS_FORM_DEFAULT_VIEW,
+    '#multiple' => false,
+    '#page' => 0,
+    '#collapsed' => false,
+    '#collapsible' => false,
+    '#arguments' => array(),
+    '#embedded' => false, // kratib: This new setting controls whether we're embedding the selector in its own view.

I'm philosophically opposed to the default view here. It seems extremely arbitrary, and unlikely. Can we eschew a default view and have a fail condition if a #view is needed and not provided instead?

+  // modify the view if it is a form -- remove exposed filters and add in
+  // any items that have been selected by the user
+  if($view->page_type == 'form') {
+    if ($view->missing) {
+      $items = array_merge($view->missing, $items);
+    }
+    $view->exposed_filter = array();
+  }

I've been trying to get away from hard coding the type here. Instead, I've been relying on flags set in the plugin data. For example, 'needs table header' is used for the table type so that it knows it needs a header. That way other plugins can use the same basic ideas. Also, this means that the form style plugin only works on page views, and there may be use cases where simple forms may be used in blocks.

+  if ($display_only) {
+    foreach($views_style_plugins['base'] as $plugin => $def) {
+      if ($def['hide'] == true) {
+        unset($return['base'][$plugin]);
+        unset($return['titles'][$plugin]);
+      }
+    }
+  }

I may be wrong here, but it seems to me that if $titles == TRUE we're displaying, and if $titles == FALSE we need the full data. Also, we could probably be more efficient with array_filter in either case.

+      'include_exclude' => array(
+        'name' => t('Node: Include/Exclude Nodes'),
+        'field' => 'nid',
+        'operator' => 'views_handler_operator_or',
+        'value' => views_handler_filter_nid_value_form(VIEWS_FORM_DEFAULT_VIEW),
+        'value-type' => 'array',
+        'help' => t('This filter allows you to limit your view to only apply to some specific nodes. You can limit your view to a specific list of nodes, or you can exclude specific nodes from every being returned.'),
+      ),

This is going to be really confusing to users. How are they to know that 'frontpage' is what this is limiting their nodes to? We probably need to create a way to include views specifically. This one might be more complex; I'd initially thought to just include all views, but at this point we may not actually know about all views. So instead, we probably need some way to add views to a list, and then each one of them is then given its own include_exclude filter.

subscribe

the bulk operations module depends on this patch. if anyone has time to work on it, that would be swell.

I'm planning to try to dive into it this weekend. I'll be looking for help on IRC, though.

subscribing

subscribing

Subscribe

ok, I'm starting to get an idea of what this does, but it seems that this patch doesn't really provide much of any functionality without an additional module that builds forms? Am I missing something?

If I select for a page "View Type:" of "View form" I just get a blank page. That doesn't seem right... Or is that what needs to be done so that another module can use it in a form?

Here's a new patch which includes the .inc file as well. Not modified at all except to put it all in one patch.

Perhaps this can be simplified a bit - is the added filter element necessary for the basic functionality? I can't even see that it works.

comment #71 form_element_2.patch appears to be corrupt. please use the files from #57 and #61 if you'd like to patch views.

the style plugin currently provided by this patch indeed does nothing and should probably go away. this patch should not result in any visible changes to views. it should, instead, simply allow for a new form element to be used called 'views_node_selector', which when implemented by a module (such as: http://drupal.org/project/views_bulk_operations) will enable the node selector functionality we're all so anxious to see :)

see this screenshot for better understanding: http://drupal.org/files/issues/views_bulk_operations.png

While waiting for the trimmed down patch - playing with this with the VBO, or a my own very trimmed down version, everything looks pretty good.

Note - if there is no default style plugin, the #embeded attribute will always be true, and so can be eliminated, right?

Thinking further about how to make this the most generally useful functionality - we should be able to pass in a list of checkboxes that are disabled, as well as passing in the ones that are checked by default.

To do this, however, it seems would require re-implementing these 2 functions:

http://api.drupal.org/api/function/expand_radios/5

http://api.drupal.org/api/function/expand_checkboxes/5

subscribing

Subscribe

ok - this patch is a radical simplification and tries to more appropriately fit within the way Views normally works. However, I think all the essential functionality to make it relatively easy for a module to turn a view into a form is retained.

Note, it seems to me that for Views Bulk Operations module, it should be theming the entire view, rather than just making a plugin. In the Views module, the general theme function - theme_views_view() - produces this sort of output:

---
header
---
exposed filters
---
content - themed via plugin (a.k.a. depending on page_type or block_type)
---
footer
---
pager
---

So, instead of (or in addition to) the plugin in the VBO module, if you want control over display of the exposed filters and pager in VBO module, it seems that you should implement theme_views_view_admin_content().

Here's a minimal module that demonstrates the functionality of the patch - the _submit functions just use drupal_set_message() to show the values, they don't do anything else.

note- you need to save-as to get rid of the .info extension (needed to trick project into letting me upload a tarball)

Another great way to try this out is with the views bulk operations module: http://drupal.org/project/views_bulk_operations

The latest version is designed to work with patch #79 (tks pwolanin)

If you're interested in helping test this patch and/or views bulk operations and need help setting it up, contact me. But all you need to do is apply patch #79 to views version DRUPAL-5--1-6 and install the VBO module.

I would very much like to use this on an intranet, but am unsure how to proceed. The patch file on comment #43 appears to be the most recent, but it is not against the current version of Views (current views.module is 1.166.2.43 and the patch references 1.166.2.41). How can I get this implemented now?

I have a CCK (purchase request) and the user has to select from a list of vendors. A vendor is a CCK in my system, and I currently use a Node Reference as a Select List when the user has to specify. It is unwieldy with 600 vendors though. I am hoping that this patch will allow me to show a View of the vendors instead, with filtering/search so the user can navigate the vendor list easily. Am I on the right track?

Thanks!

Oops, never mind - I found the newer version of the patch by pwolanin, missed it the first time.

This is great functionality!! What are the odds of someone making the noderefselector use ajax to search the view instead of doing a page refresh? (I know, I want the world. . .)

Thanks so much for this!

I've been using patch #79 (and the views bulk operations module) in a dev environment for a couple weeks now. I've run into no problems.

This latest patch includes minimal changes to existing views code. I think it's more than ready to be included in the next beta release of views.

Hi ,

I am a newbie and having problems in installing views bulk operations module. Currently. I am using

Drupal 5.2
CCK 5.x 1-6
views 5.x 1-6

As described in comment #84, I have applied the patch from #79 and copied the VBO from CVS repository directory to my drupal/sites/all/modules/view_VOB directory . There are now three files in the directory which are:
views_bulk_operations.css
views_bulk_operations.module
views_bulk_operations.info

The following warning is given as I attempted to list the module in drupal/administer/site building/modules :

warning: Error parsing sites/all/modules/views_VOB/views_bulk_operations.info on line 5 in C:\xampp\htdocs\drupal-5.2\includes\module.inc on line 195.

And VBO was not in module list.

Selda

sorry , I have changed the title by mistaken

@Bedestenlioglu :if you are having problems with the VBO module, please file the issue there: http://drupal.org/project/issues/views_bulk_operations

This patch and views bulk operations are not released. There is no support and they are not guaranteed to work. That being said, I am using both in a semi-production environment and they are stable. But you have to know what you're doing to get them both working.

subscribing...

I'm going to begin work on an alternate implementation of views forms: http://drupal.org/node/188276

Trying to move to v5, as using subforms on v4.7.

Hopefully this could solve my problem.

Subscribing.

subscribing
greetings,
Martijn

Is this patch in Limbo, or will it eventually get committed? Since it was offered almost a year ago, I'm concerned that the views team really doesn't want to go this way.

Too bad, cause the idea behind the Views Bulk Operations mod is great, but I don't necessarily want to support it over time with a patch to each Views update.

@rleigh - see #91. Apparently this isn't the "best" way to approach the problem. However, Harry seems not to have made much progress. Maybe I'll go ahead and make this a module - but it's unlikely to get updated for 6.x (i.e. Views2).

We're happy to announce that the Views Bulk Operations module no longer depends on this patch to run. We released today VBO-1.0-Beta 1 which is 100% patch-free! Great thanks go to pwolanin whose simplified patch was successfully integrated inside VBO instead of being applied to Views.

So is this patch still working? Still going forward. Just to clarify. Thanks.

@JK_drupal - it seems essentially that this patch will not become part of views. See #91 and #96 above and my earlier comments. Since the patch made essentially no changes to the main views module, it can just be added on as a separate module for those that want to use it. I'll probably close this issue soon.

Hi,

Will it then not be smart to build the module to have it available for all (on Drupal 5 for instance at first)?

Happy Year-ending.
Greetings,
Martijn

@Martijnhaan - this is essentially being maintained now as part of the VBO module. You can use the .inc file from there with your own module if you want to do something different.