Views configuration example

Unfortunately, it may not be that simple :)

This is some basic example. It will create a page display and assign it a path. Sarva is working on filling in the blanks. You may expect more details soon.

  - tag: view
      action: update
      details:
        name: blog
        description: The site's blog.
        tag: blog
        base: node
      display:
        - name: default
          section:
            - name: row_plugin
              value: node
            - name: use_pager
              value: 1
              data:
                pager_element: 2
            - name: items_per_page
              value: 10
          item:
            - type: filter
              name: node.type
              data:
                operator: in
                value:
                  blog: blog
            - type: filter
              name: node.status
              data:
                operator: =
                value: 1
            - type: sort
              name: node.created
              data:
                order: DESC
                granularity: minute
        - name: page
          section:
            - name: path
              value: blog

subscribing

subscribing.

Hi,

I am using the following example to create my first View Pattern, however I cannot figure out how to insert Fields into the view, can you help me out?

I'm have tried something like this:

  <item>
    <type>field</type>
    <name>field_heading</name>
      <value>
        <data>
          <format>trimmed</format>
        </data>
       </value>
   </item>

Example View:

<actions>
    <view>
      <!--
        The action element lets you specify the type of action you would like to perform on this view.
        An insert action only works if the view does not exist while an update action will try and
        create a view for you if it does not exist first (default). 'remove' will delete the view
      -->
      <action>update</action>
      <!--
        Core view information, name, description, tag, and base go inside details.
        name and base are required for new views while either name or vid are required for existing views
      -->
      <details>
      <name>view_test</name>
      <description>This is a test view</description>
        <tag>viewtag</tag>
        <base>node</base>
      </details>
      <!--
        Any action on a display must go inside a display element. Each display element must also
        specify its ID via the name element. The default display will be used for the first display
        that does not specify a name. You can set the 'action' element to 'delete' to specify a
        display for deletion. The default action is 'update'       
      -->
    <display>
      <!--
          Any change to values inside Basic Settings or Page/Block/etc settings go inside
          a section element. There should be one section element per change. The simplest way
          to specify changes is to provide the name and value elements. Sometimes a section
          requires more information in which extra keys can go inside a 'data' element.
        -->
        <section>
          <name>display_title</name>
          <value>Default Display</value>
        </section>
        <section>
          <name>title</name>
          <value>View Edits</value>
        </section>
        <section>
          <name>style_plugin</name>
          <value>grid</value>
        </section>
        <section>
          <name>style_options</name>
          <value>
            <columns>3</columns>
            <alignment>horizontal</alignment>
          </value>
        </section>
    <section>
      <name>row_plugin</name>
          <value>node</value>
    </section>
        <section>
          <name>use_ajax</name>
          <value>1</value>
        </section>
        <section>
          <name>use_pager</name>
          <value>1</value>
          <values>
            <pager_element>2</pager_element>
          </values>
        </section>
        <section>
          <name>items_per_page</name>
          <value>15</value>
          <values>
            <offset>3</offset>
          </values>
        </section>
        <section>
          <name>use_more</name>
          <value>1</value>
        </section>
        <section>
          <name>distinct</name>
          <value>1</value>
        </section>
        <section>
          <name>access</name>
          <value>
            <type>role</type>
          </value>
        </section>
        <section>
          <name>access_options</name>
          <value>
            <type>role</type>
            <role>1</role>
            <role>2</role>
          </value>
        </section>
        <section>
          <name>exposed_block</name>
          <value>1</value>
        </section>
        <section>
          <name>header</name>
          <value>This is the view header</value>
          <values>
            <header_empty>1</header_empty>
            <header_format>2</header_format>
          </values>
        </section>
        <!--
          Adding/configuring filters/sorts/fields/arguments/relationships is handled by the
          item element. The type and name fields are required. An action element can be
          used to 'remove' the item while the default action is 'update' ('insert' is available).
          Any standard data configuration goes inside the 'data' element while extra data configurations
          go inside an 'extra' element. Styling options go inside a 'style' element
        -->
        <item>
          <type>relationship</type>
          <name>comments.uid</name>
          <data>
            <label>User</label>
            <required>1</required>
          </data>
        </item>
        <item>
          <type>argument</type>
          <name>node.nid</name>
          <data>
            <title>%1</title>
            <default_action>not found</default_action>
            <default_argument_type>node</default_argument_type>
            <validate_type>node</validate_type>
            <validate_argument_node_type>
              <page />
            </validate_argument_node_type>
            <validate_argument_nid_type>nids</validate_argument_nid_type>
            <validate_fail>not found</validate_fail>
          </data>
          <style>
            <count>1</count>
            <items_per_page>15</items_per_page>
          </style>
        </item>
        <item>
          <type>sort</type>
          <name>node.created</name>
          <data>
            <order>DESC</order>
            <granularity>minute</granularity>
          </data>
        </item>
        <item>
          <type>filter</type>
          <name>node.type</name>
          <data>
            <value>
              <story />
            </value>
            <operator>in</operator>
          </data>
        </item>
    </display>
      <display>
        <name>page</name>
        <section>
          <name>path</name>
          <value>view/test</value>
        </section>
      </display>
    </view>
</actions>

have you considered the ability to be able to use a views export text? this way you can just make a view, export it, and paste the resulting code into the pattern.

@bigmack, we have considered and written code so that direct views exports can be pasted into Patterns. Vaish or Sarva will have to review and comment on the current state of that in the code.

If it's not in the the current release it should be pretty easy to add back in.

Awesome, slighly off topic but related: is there similar functionality for export text from cck fields, imagecache presets, panels, and so on? Well I can see panels might take quite a bit loger to be supported but curious if its something on the egenda in the future. Are there any docs stating what export code from various modules are supported?

Here's a component I use to do this. Placed under /patterns/components/views_ui.inc
I can then define an 'action' like so:

$pattern = array(
  'info' => array(
    'title'   => '(Views): Create an archive of mailed out newsletters."',
    'description' => 'Adds a menu link also',
    'author'  => 'dman',
    'author_email' => 'dan@coders.co.nz',
    'version'  => '0.1',
    'category' => 'Coders',
    'core'     => '6.x',

  ),
  'modules' => array(
    'views',
  ),
  'actions' => array(
    # This uses a custom patterns handler - views_import
    array(
      'tag' => 'views_import',
      // FORM VALUES:
      'name'      => 'Newsletters',
      'filename'  => dirname(__FILE__) ."/205-views_newsletters.view.inc",
      'view'      => "",
    ),
  ),
);

(I use php, not XML or YAML for my patterns - because they contain logic)

and 205-views_newsletters.view.inc is a direct views export defintion dump.

$view = new view;
$view->name = 'newsletters';
$view->description = '';
$view->tag = '';
$view->view_php = '';
$view->base_table = 'node';
...
..

The same action can be invoked via XML or YAML by just making up something with tag='views_import'

Alternatively, you can just paste the raw view code directly into the view='' space. I don't because unescaping code is a bore.

Component for importing views export dump has just been committed. Thanks to dman for inspiration to keep it as a separate inc file as well as for adding "filename" option.

@dman: you may be interested to check out views import component I committed and compare it to yours from #9. I'll be happy to answer your questions if you have any.

Using the CRUD or PHP objects/structures that other modules - panels, views - use is definately a win compared to spending so much effort to emulate it in a new language!

Plus it's 4x more likely that you'll be able to upgrade between versions!

Laziness is a virtue!

I'll have a look at the latest version next time I'm rolling some patterns. The ones we've been using are pretty stable right now, so don't wanna break them. But if you are looking at panels ... this works there too!

That's absolutely true but such objects/structures are not always available. Also how do you use view import code to update existing view - for example changing the number of items per page, adding a new field or filter or changing sort criteria?

That was a reason why our original intention was to implement components for full Drupal core and as many modules as possible. However, those components proved to be very difficult to maintain so we are shifting our focus more towards native module's exportable structures and "form" action wherever such structures are not available.

Yes, panels support is on my todo list but I'm not sure when I'll get to it.