Views Forms

To answer #7 - Earl has suggested that approach is not the right one. See http://www.angrydonuts.com/how-to-do-forms-and-views-properly

Regarding availability and what versions will be available. The focus is on views 1.6 for Drupal5. If this is successful, then it would be ported to whatever version of Views is available for Drupal6 (which looks like it will still be views 1 according to Earl).

Had a brainstorming with kratib, and here's a sketch of the thing we will try to implement:

New view type

There will be a new type of view called 'form' which will exist along with the 2 current view types 'page', and 'block'.

This type will be nearly identical to the 'page' view type with the exception that it will have an additional field for selecting the desired form handler.

By default, there will be one available form handler for views called something like 'administer nodes' and will provide a form similar to 'admin/content/node'.

The magic will happen with other modules (like 'views bulk operations') make available additional types of forms.

hook_views_tables() will include form field definitions

Right now, modules define fields for pages or blocks using something like this:

function node_views_tables() {
...
    'fields' => array(
      'title' => array(
        'name' => t('Node: Title'),
        'handler' => array(
          'views_handler_field_nodelink'           => t('Normal'),
          'views_handler_field_nodelink_with_mark' => t('With updated mark')
        ),
        'option' => array(
           '#type' => 'select',
           '#options' => array(
             'link' => 'As link',
             'nolink' => 'Without link'
            ),
        ),
        'sortable' => true,
        'addlfields' => array('changed'),
        'help' => t('Display the title of the node.'),
      ),
...
}

We will add a property in here somewhere that will flag a field definition as being of type 'form', and it will be responsible for defining one or more form elements that will be made available for a given value. For example, the $node->author field might make available a user_autocomplete() field as well as a simple dropdown.

Views fields will have a new property

Form fields are still 'fields', but they should not be handled in the same way a read-only field is handled. So we're going to add a new option. Using ViewsUI, you'd see a new column in the 'fields' configuration section called something like 'form options', where a dropdown list would be made available if that field had form options. So our $node->author field would have available 3 options: 1) Read-only 2) User autocomplete field 3) User dropdown selector

So when your view is displayed, it would have all the same behavior as before with the exception that if the view was a form, we'd pull in the selected form fields and set a submit handler according to the view configuration.

More to it

There will be other things involved obviously. For example, we'll need a way for modules to add custom things to forms. Like views bulk operations will need to be able to add its operation selector widget.

I'm working on this as time permits, but because my client has a functioning version 'views bulk operations' right now, other things tend to jump ahead in the queue. But I realize that we can't limp along on this temporary solution for long, so am pushing for this views-forms effort as much as possible.

fyi, as i work on this, i'll also idle in here: irc://irc.freenode.net/drupal-views-forms

if you want to help, join me there.

I'm going to discontinue this effort for several reasons:

1) The views bulk operations module no longer depends on this functionality being built into views, and so I am now patch-free.

2) Doing this right will require more of Earl's time than he has right now. I don't want to go down the wrong path and have to rewrite again and again.