Views configuration example
michaek - March 5, 2009 - 21:03
| Project: | Patterns |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | support request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
Hi, folks.
I was hoping you might be able to provide an example of configuring views in a pattern. What I've got so far adds a view, but doesn't configure any displays for it. I'm sure there's something simple I'm missing. Here's what I've got so far (an attempt to configure the default display):
<view>
<details>
<name>myview</name>
<description>A view for my nodes</description>
<base_table>node</base_table>
</details>
<display>
<title>My View</title>
<sorts>
<timestamp>
<order>DESC</order>
<granularity>second</granularity>
<id>created</id>
<table>node</table>
<field>created</field>
</timestamp>
</sorts>
</display>
</view>Thanks!
#1
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: viewaction: 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
#2
subscribing
#3
Thanks so much, Vaish. I'll let you know how it works for us!
#4
subscribing.
#5
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>
#6
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.
#7
@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.
#8
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?
#9
Here's a component I use to do this. Placed under /patterns/components/views_ui.inc
I can then define an 'action' like so:
<?php
$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.incis 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.