Commit 49ebc602 authored by The Great Git Migration's avatar The Great Git Migration Committed by Drupal Git User (LDAP)

Stripping CVS keywords

parent 6f597e86
// $Id$
Welcome to Views 2. Please see the advanced help for more information.
......
/* $Id$ */
/*
* Summary pad
......
/* $Id$ */
table.views-entry {
clear: right; /* RTL */
......
/* $Id$ */
table.views-entry {
margin: 3px 0;
......
/* $Id$ */
.views-exposed-form .views-exposed-widget {
float: left;
padding: .5em 1em 0 0;
......
<?php
// $Id$
/**
* @file
* This file contains no working PHP code; it exists to provide additional documentation
......
<?php
// $Id$
/**
* @defgroup views_argument_handlers Handlers for arguments
......
<?php
// $Id$
/**
* Abstract argument handler for dates.
*
......
<?php
// $Id$
/**
* Abstract argument handler for simple formulae.
*
......
<?php
// $Id$
/**
* An argument handler for use in fields that have a many to one relationship
* with the table(s) to the left. This adds a bunch of options that are
......
<?php
// $Id$
/**
* Argument handler that ignores the argument.
*/
......
<?php
// $Id$
/**
* @file
* Contains the numeric argument handler.
......
<?php
// $Id$
/**
* Basic argument handler to implement string arguments that may have length
......
<?php
// $Id$
/**
* @defgroup views_field_handlers Views' field handlers
* @{
......
<?php
// $Id$
/**
* A handler to provide proper displays for booleans.
......
<?php
// $Id$
class views_handler_field_counter extends views_handler_field {
function option_definition() {
......
<?php
// $Id$
/**
* A handler to provide a field that is completely custom by the administrator.
......
<?php
// $Id$
/**
* A handler to provide proper displays for dates.
*
......
<?php
// $Id$
/**
* A handler to run a field through check_markup, using a companion
......
<?php
// $Id$
/**
* Render a field as a numeric value
*
......
<?php
// $Id$
/**
* Field handler to provide a list of items.
......
<?php
// $Id$
/**
* Field handler to provide simple renderer that turns a URL into a clickable link.
......
<?php
// $Id$
/**
* @defgroup views_filter_handlers Views' filter handlers
* @{
......
<?php
// $Id$
/**
* Simple filter to handle matching of boolean values
*
......
<?php
// $Id$
/**
* Simple filter to handle matching of boolean values.
*
......
<?php
// $Id$
/**
* Filter to handle dates stored as a timestamp.
......
<?php
// $Id$
/**
* Simple filter to handle equal to / not equal to filters
*/
......
<?php
// $Id$
/**
* Simple filter to handle greater than/less than filters.
......
<?php
// $Id$
/**
* Simple filter to handle matching of multiple options selectable via checkboxes
*
......
<?php
// $Id$
/**
* Complex filter to handle filtering for many to one relationships,
......
<?php
// $Id$
/**
* Simple filter to handle greater than/less than filters
......
<?php
// $Id$
/**
* Basic textfield filter to handle string filtering commands
......
<?php
// $Id$
/**
* @file
* Views' relationship handlers.
......
<?php
// $Id$
/**
* @defgroup views_sort_handlers Views' sort handlers
* @{
......
<?php
// $Id$
/**
* Basic sort handler for dates.
......
<?php
// $Id$
/**
* Base sort handler that has no options and performs a simple sort
*
......
<?php
// $Id$
/**
* Sort in menu hierarchy order.
......
<?php
// $Id$
/**
* Handle a random sort.
......
<!-- $Id$ -->
The views module allows administrators and site designers to create, manage, and display lists of content. Each list managed by the views module is known as a "view", and the output of a view is known as a "display". Displays are provided in either block or page form, and a single view may have multiple displays. Optional navigation aids, including a system path and menu item, can be set for each page-based display of a view. By default, views may be created that list content (a <em>Node</em> view type), content revisions (a <em>Node revisions</em> view type) or users (a <em>User</em> view type). A view may be restricted to members of specific user roles, and may be added, edited or deleted at the <a href="base_url:admin/build/views">views administration page</a>
The "building block" design of the views system provides power and flexibility, allowing parameters to be specified only when needed. While an advanced view may use all of available parameters to create complex and highly interactive applications, a simple content listing may specify only a few options. All views rely on a conceptual framework that includes:
......
<!-- $Id$ -->
<p>You may use any of the following possible theme files to modify individual parts of your view. In total, there are four parts to theming a view.</p>
<ul>
<li> The <strong>display</strong> theme is usually views-view.tpl.php and it largely controls the decorations around a view; where the header, footer, pager, more link, feed icon, etc, will be placed. </li>
......
<!-- $Id$ -->
Views can be stored in the database, which is typical of smaller sites and hobby sites. However, Views may also be stored directly in the code as "default" views, (which simply means they're available by default). Modules often come with views that are specific to the module data, but it's also possible -- and <b>highly</b> recommended -- that sites which have separate "development" and "production" sites export their views into default views in a site-specific module. This makes it very easy to transfer views from dev to production without making database changes.
<h3>Creating a module</h3>
......
<!-- $Id$ -->
For the new table defined by the Node example module to be understood by the views module you need to create a node_example.views.inc file that describes the table and its relationships to the rest of the database. In order for views to know that this file is to be loaded you need to implement hook_views_api. This is done by adding the following function into your node_example.module file
......@@ -24,7 +23,6 @@ Below is the contents of a simple node_example.views.inc file that allows you to
<pre>
&lt;?php
// $Id$
/**
* This file is used to tell the views module about the new node_example table.
......
<!-- $Id$ -->
In Views, a handler is an object that is part of the view and is part of the query building flow.
Handlers are objects; much of the time, the base handlers will work, but often you'll need to override the handler for something. One typical handler override will be views_handler_filter_operator_in which allows you to have a filter select from a list of options; you'll need to override this to provide your list.
......
<!-- $Id$ -->
In Views, a plugin is a bit like a handler, but plugins are not directly responsible for building the query. Instead, they are objects that are used to display the view or make other modifications.
There are 6 types of plugins in Views:
......
<!-- $Id$ -->
Tables are described to Views via hook_views_data(), which returns an array of table information, keyed by the name of the table. For example, if your module is describing three tables, 'foo', 'bar' and 'baz', your array will look like this:
<pre>$data = array(
'foo' =&gt; array(
......
<!-- $Id$ -->
Views allows modules to describe their tables relationships to each other, as well as fields, filters, sort criteria and arguments via <strong>hook_views_data()</strong>. Whenever Views deems it necessary, this hook is called, the data aggregated together and cached. <strong>hook_views_data_alter()</strong> may also be used to modify existing data, changing other module's handlers or adding handlers to other module's tables.
Views also allows modules to create new display types, style types, row styles, argument default handlers and argument validators via <strong>hook_views_handlers()</strong> and <strong>hook_views_plugins()</strong>.
......
<!-- $Id$ -->
Arguments are input. While they often come from the URL, <strong>they don't always</strong> so please don't be shocked when they don't. Each display type may have its own source for arguments. Block displays have no source of arguments at all; they cannot pull arguments from the URL, and often require use of the default argument PHP code in order to get arguments. The argument default plugins can be used to get arguments into a block view. See "Provide default", below.
In general, arguments are used to filter the view, and in that sense they have a very close relationship to filters, but that isn't necessarily true for every argument. Arguments can be used for any purpose, really; the extent of what the argument does is up to the developer of the argument, but the arguments that come with Views are almost entirely filters.
......
<!-- $Id$ -->
Attachment displays are 'attached' to another display in the same view. When the display is visited, the attached display will also be rendered and may be placed before, after or both before and after the original display. Attachment displays are often useful for displaying an argument summary view along with a page display that accepts arguments. This can be used to provide a kind of glossary.
\ No newline at end of file
<!-- $Id$ -->
Block displays will show up on your blocks administration page. Once a block display is created and saved, it can be enabled and positioned in your theme by visiting <strong>administer &gt;&gt; site building &gt;&gt; blocks</strong> and selecting it from the list.
Blocks <strong>do not</strong> accept arguments from any source; the only way to get arguments to a block is to provide defaults to it, possibly via the PHP Code default setting.
......
<!-- $Id$ -->
The default display is primarily a display to store settings, and isn't actually used anywhere within the Views system. It is possible for external programs to use the default display, but if they do they will (hopefully) tell you which display they will be working with. The default display is also a convenient display to use to embed into your site using PHP snippets; this is useful, for example, in node content, but this is something that should generally only be done by administrators.
In general, you probably want to add either a <a href="topic:views/display-page">page display</a> or a <a href="topic:views/display-block">block display</a>.
......
<!-- $Id$ -->
A feed display allows you to attach an RSS feed to a view.
\ No newline at end of file
<!-- $Id$ -->
Page displays have a <a href="topic:views/path">path</a> and an optional <a href="topic:views/menu">menu</a> component. Page displays will be the primary content for the page, meaning they will be displayed in the main content area when you visit the URL that corresponds to the path.
Page displays take their arguments from the URL. You can embed arguments into the URL using %; in previous versions of Views, this was '$arg'. For example, 'node/%/foo' will accept URLs such as 'node/1/foo'.
\ No newline at end of file
<!-- $Id$ -->
Displays tell Views where the output should go. By adding a display to a View, you can have your view appear as a page, or as a block, or even as an attachment to a different display on the view.
Each display can have its own settings, but when it's created, a display will take all of its <em>basic settings</em> from the <strong>default display</strong> which all Views must have. For most settings, there is an <strong>override</strong> button that will override that single setting for the current display. Overridden settings will have a mark in the summary for that display.
......
<!-- $Id$ -->
You can easily embed the results of a view into other parts of your site;
either with code as a module, or in nodes or blocks as snippets. The
easiest way is to use the function <strong>views_embed_view()</strong>:
......
<!-- $Id$ -->
<p>In this example you will create a context-sensitive block that shows the titles of recent blog entries by an author when viewing one of their posts. This will demonstrate using Views <em>arguments</em> to dynamically filter a view's contents at display time.</p>
<p>Before working through this example, enable the <strong>Blog</strong> module and populate some entries from a few different users.</p>
......
<!-- $Id$ -->
In this example you will create a list of nodes of the content type "story", to be shown in a block. Through this step-by-step process, you will become familiar with some basic steps in creating a view, and familiarize yourself with the Views User Interface.
<ol>
......
<!-- $Id$ -->
<p>In this example you will create a <em>Feed display</em> to show nodes by individual users, dynamically selected through the URL. You will become familiar with the Views 2 interface, as well as learn how to use an argument to pull in a user name and use it in a dynamically created path.</p>
<p>A <em>feed</em> is a data format that places your site's content into a file that can be read and displayed by news reader programs. When visiting a site, you may notice a small <a href="http://drupal.org/misc/feed.png">RSS transmission icon</a>, whereby clicking on it, you can subscribe to the site's most recent content. This makes it easier for your visitors to keep up to date with your website. You can also use this format to aggregate information into other sites. For more information, please watch a video from Common Craft about <a href="http://www.commoncraft.com/rss_plain_english">RSS in plain English</a>.</p>
<p>Note, Drupal automatically creates a feed for your website, but you may want to create feeds with specific information. In this case, a list per user. </p>
......
<!-- $Id$ -->
In this example you will create a page view listing users on your site. Through this step-by-step process, you will become familiar with some basic steps in creating a view, and familiarize yourself with the Views User Interface.
<ol>
......
<!-- $Id$ -->
Fields are the individual pieces of data being displayed. Adding the fields <em>Node: Title</em>, <em>Node: Type</em>, and <em>Node: Post date</em> to a node view, for example, includes the title, content type and creation date in the displayed results).
Fields may not appear on every display, because not all style plugins actually use fields. For example, the 'node' row plugin simply displays the node through Drupal's normal mechanisms, and fields are not involved.
......
<!-- $Id$ -->
Filters are used to reduce the data set that Views provides. That is to say, without any filters applied, Views will return all of your content. You don't want that, so at least some filters must be used.
Some very commonly used filters:
......
<!-- $Id$ -->
For those new to Views, it can be a complex system that appears totally overwhelming. The good news is that the UI is designed to compartmentalize everything; this means that for the most part, you can ignore the parts you're not interested in. Start small and build your way up.
Because of this, the edit UI can seem overwhelming at first, but there are really just a few things you <strong>have</strong> to know. The rest you can find through exploration. The Views Edit UI image, below, gives an overview of what you'll find on the edit UI.
......
<!-- $Id$ -->
Page displays can hook into the Drupal menu system and provide <strong>menu links</strong> that will appear in the Navigation system as well as <strong>tabs</strong> that can be used to keep Views next to each other.
For simple <strong>menu links</strong>, there is very little you need to do; simply select 'Normal menu entry' and fill in the text for the title. This will appear in the Navigation menu by default; you will need to visit the menu administration page to move this to another menu.
......
<!-- $Id$ -->
Views 2 is the newest major release of Views and it is specifically coded for Drupal 6. Views 2 retains all of the core functionality of Views 1, together with a completely revamped user interface and a large set of new features which greatly expand upon the original feature-set of Views 1. This document is a side-by-side comparison of Views 1 versus Views 2 from a user's perspective, detailing the UI changes, some new ways to perform old tasks, the cool new features of Views 2 and how these features can be used to address some of the shortcomings of Views 1.
<h2>Admin interface</h2>
......
<!-- $Id$ -->
If an item is <strong>using defaults</strong> then it is using values from the <strong>default display</strong>. <em>IMPORTANT NOTE:</em> If you modify this value, you are modifying the <strong>default display</strong> and thus modifying for all displays that are using default values.
......
<!-- $Id$ -->
If a display has a path that means that it can be retrieved directly by calling a URL as a first class page on your Drupal site. Any items after the path will be passed into the view as arguments. For example, if the path is <strong>foo/bar</strong> and a user visits <strong>http://www.example.com/foo/bar/baz/beta</strong>, 'baz' and 'beta' will be given as arguments to the view. These can be handled by adding items to the <a href="topic:views/arguments">arguments</a> section.
You may also use placeholders in your path to represent arguments that come in the middle. For example, the path <strong>node/%/someview</strong> would expect the first argument to be the second part of the path. For example, <strong>node/21/someview</strong> would have an argument of '21'.
......
<!-- $Id$ -->
Relationships allow you to expand the query to include objects other than the base query. This is actually made more difficult to understand by the fact that Views actually includes a few relationships by default, and doesn't tell you they're there. For historical reasons, it would be inconvenient to remove these default relationships. When relationships are present, all fields (including relationships) will gain a new form item to let you select which relationship they will use. They will default to using no relationship at all.
The main example of the relationship that is there by default is the node --&gt; user relationship; every node has an author, and if a node is in the query, the user who wrote that node is automatically made available. [Note: the author considers it an error that this relationship is automatic, but by the time it was realized this was in error, it was too late to change it.]
......
<!-- $Id$ -->
Sort criteria determine what order the records are retrieved from the database and displayed in; generally, all you need to do is pick a field and choose ascending (1, 2, 3, 4) or descending (4, 3, 2, 1) and it will be done. If you have multiple sort criteria, the second (and later) items only come into play if the first item is the same.
Different data types sort just a little bit differently from others:
......
<!-- $Id$ -->
This row style is only available to RSS styles. It produces XML necessary for an RSS feed for the comment.
\ No newline at end of file
<!-- $Id$ -->
The <strong>fields</strong> row style displays each field defined in the view, one after another. Each field defines its own output.
By default, each field is put in a &lt;div&gt; unless it is selected to be <em>inline</em>. If it is inline, it is put in a &lt;span&gt;. Two items in &lt;div&gt;s will be displayed one after another, with the second one below the first. Two items in &lt;span&gt;s will be displayed on the same line. One item in a &lt;span&gt; next to &lt;div&gt;s is the same as two items in &lt;div&gt;s. This means that for the <em>inline</em> setting to do anything, at least two consecutive items must be set inline.
......
<!-- $Id$ -->
The <strong>grid</strong> style will display each row of your view within a grid. You may customize the number of columns, though it defaults to 4. A grid looks like this:
<table width="100%">
......
<!-- $Id$ -->
The <strong>List</strong> view style will display every row of the view as part of an HTML list construct. For example:
<ul>
<li> Row 1 </li>
......
<!-- $Id$ -->
This row style is only available to RSS styles. It produces XML necessary for an RSS feed for the node record.
\ No newline at end of file
<!-- $Id$ -->
The <strong>node</strong> row style will display each item of the view through Drupal's standard <em>node_view()</em> function. Views has very little control over this output, except for the options you see. Instead, the output is run through the standard node template mechanism (typically <strong>node.tpl.php</strong> or a variant thereof) and any decisions about what is output may be done there.
Views does add an extra 'suggestion' to the list of possible node templates: <strong>node-view-VIEWNAME.tpl.php</strong> -- you may use this to theme a node specifically for the view. This can be handy for creating very small teasers and the like.
......
<!-- $Id$ -->
A row style is an individual style to display only an individual record within a view. For example, a <strong>node</strong> type view would display one node per row; a <strong>user</strong> type view would display one user per row.
Some row styles use <em>fields</em> which means you select from the available fields to display; others do not; they are able to use the base type and create a display. Usually, row styles that do not use fields <em>produce less efficient (slower) views</em>, so bear this in mind when contemplating the performance of your site.
\ No newline at end of file
<!-- $Id$ -->
The <strong>RSS</strong> output style is only available for <em>Feed</em> display types. It will display the view as an RSS feed, which is a specialized XML output. This output is not user visible, but can be parsed by feed readers for aggregation.
You may supply a description for the RSS feed; most feed readers will display this description along with the contents of the feed. You may also select to use the site's mission statement for the description.
\ No newline at end of file
<!-- $Id$ -->
The <strong>unformatted summary</strong> style is only available for <em>summary</em> styles, which are when an argument has been set to provide a summary if it was not provided with a value. This summary provides the possible candidates for the argument one after another with no special formatting. If <em>inline</em> is selected, the summary items will be enclosed within &lt;span&gt; tags. Otherwise the items will be in &lt;div&gt; tags.
You can also elect to display the number of matching records for the argument, plus change the number of items per page for the summary. This is often useful because summary views are often quite small, but other views quite space intensive. It is very common to have far more records available in the summary view than in the more normal view.
\ No newline at end of file
<!-- $Id$ -->
The <strong>list summary</strong> style is only available for <em>summary</em> styles, which are when an argument has been set to provide a summary if it was not provided with a value. This summary provides a list of possible candidates for the argument in a standard HTML list. Like the normal list style, you may set this list to be ordered or not.
You can also elect to display the number of matching records for the argument, plus change the number of items per page for the summary. This is often useful because summary views are often quite small, but other views quite space intensive. It is very common to have far more records available in the summary view than in the more normal view.
\ No newline at end of file
<!-- $Id$ -->
The <strong>table</strong> style will display the View results as a table; each row of the table will correspond to a row from the view result.
When setting the table options, each field in the view will be presented with some information next to each field:
......
<!-- $Id$ -->
The unformatted output style simply places each row of the view, one after another, with no additional formatting.
<!-- $Id$ -->
The Views' <strong>style</strong> system is how you customize the output produced by your view. A view style is basically a smart theme template that processes the view data and then outputs it. All styles in Views can be <a href="topic:views/using-theme">overridden</a> by placing copies of the templates in your theme directory and then modifying them. See the <a href="topic:views/analyze-theme">theme: information</a> link available on all views to get hints for which templates a given view is using.
<div class="help-box" style="text-align:center">
......
<!-- $Id$ -->
Views uses a wide array of CSS classes on all of its content to ensure that you can easily and accurately select exactly the content you need in order to manipulate it with CSS.
Typically, every view is wrapped in a div with the name of the view as part of its class (for all these examples, we will assume the name of the view is <strong>myview</strong>), as well as the generic class 'view':
......
<!-- $Id$ -->
TODO: This document needs to be fleshed out.
<!-- $Id$ -->
Views theme templates are straightforward to use with the Drupal theming system. If you are unfamiliar with the theming system at all, you should probably at least read <a href="http://drupal.org/node/173880">drupal.org theming documentation</a>. That said, these are the important things you need to know:
<ol>
......
<!-- $Id$ -->
<p>The <strong>view type</strong> describes how this view is stored; Views is capable of having Views entirely in code that are not in the database. This allows modules to easily ship with Views built in, and it allows you to create a module to store your views for easy deployment between development and production servers.</p>
<dl>
......
; $Id$
[advanced help settings]
line break = TRUE
......
<?php
// $Id$
/**
* @file admin.inc
* Provides the Views' administrative interface.
......
<?php
// $Id$
/**
* @file ajax.inc
......
<?php
// $Id$
/**
* @file
......
<?php
// $Id$
/**
* @file
*
......
<?php
// $Id$
/**
* @file cache.inc
*
......
<?php
// $Id$
/**
* @file convert.inc
*
......
<?php
// $Id$
/**
* @file form.inc
......
<?php
// $Id$
/**
* @file handlers.inc
* Defines the various handler objects to help build and display views.
......
<?php
// $Id$
/**
* @file plugins.inc
* Built in plugins for Views output handling.
......
<?php
// $Id$
/**
* @file query.inc
* Defines the query object which is the underlying layer in a View.
......
<?php
// $Id$
/**
* @file
*
......
<?php
// $Id$
/**
* @file view.inc
* Provides the view object type and associated methods.
......
// $Id$
/**
* @file ajax_admin.js
*
......
// $Id$
/**
* @file ajaxView.js
......
// $Id$
/**
* @file base.js
*
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.