1. nittany7 modules/contrib/ctools/help/about.html
  2. nittany7 modules/contrib/ctools/page_manager/help/about.html
  3. nittany7 modules/contrib/views/help/about.html
  4. cis7 modules/contrib/nodequeue/help/about.html
  5. cis7 modules/contrib/ctools/page_manager/help/about.html
  6. cis7 modules/contrib/ctools/help/about.html
  7. cis7 modules/contrib/views/help/about.html
  8. mooc7 modules/contrib/ctools/help/about.html
  9. mooc7 modules/contrib/views/help/about.html
  10. mooc7 modules/contrib/ctools/page_manager/help/about.html


View source
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/structure/views">views administration page</a>.

For more technical users, views can be understood as a user interface to compose SQL-queries and to pull information (Content, Users, etc.) from the database and show it on a screen as desired.

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:

  <li><a href="topic:views/field">Fields</a>, or 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 </li>

  <li><a href="topic:views/relationship">Relationships</a>, or information about how data elements relate to one another. If relationship data is available, like that provided by a CCK <em>nodereference</em> field, items from a related node may be included in the view </li>

  <li><a href="topic:views/argument">Arguments</a>, or additional parameters that dynamically refine the view results, passed as part of the path. Adding an argument of <em>Node: Type</em> to a node view with a path of "content", for example, dynamically filters the displayed items by content type. In this example (shown with Clean URLs enabled), accessing the view through the path "<em>http://www.example.com/content/page</em>" displays all posts of the type "page", the path "<em>http://www.example.com/content/story</em>" displays all posts of the type "story", and "<em>http://www.example.com/content</em>" displays all posts regardless of type) </li>

  <li><a href="topic:views/sort">Sort criteria</a>, which determine the order of items displayed in the view results. Adding the sort criteria <em>Node: Post date</em> (in descending order) to a node <em>view</em>, for example, sorts the displayed posts in descending order by creation date </li>

  <li><a href="topic:views/filter">Filters</a>, which limit items displayed in the results. Adding the filter <em>Node: Published</em> (and setting it equal to "Published") to a node view, for example, prevents unpublished items from being displayed</li>

  <li><a href="topic:views/display">Displays</a>, which control where the output will be seen. Every view has a default display, which doesn't actually display the view anywhere, but is used to hold the default settings for the view, and is used when the view is called programmatically if another display is not specified. Much more useful to users are the <a href="topic:views/display-page">page</a> display, which gives a view a path and allows it to be the primary content of a page, or the <a href="topic:views/display-block">block</a> display which allows it to appear as secondary content on other pages.</li>

<li><a href="topic:views/header">Header</a>, which allow you to add by default one or more text area above the views output. </li>

	<li><a href="topic:views/footer">Footer</a>, which allow you to add by default one or more text area beneath the views output. </li>

	<li>The <a href="topic:views/footer">Emtpy Text</a> content will be displayed, when you choose in the Arguments Section "Action to take if argument is not present" the option "Display empty text".</li>


Parallels between the components in the Views interface and an sql query:

      <th>Sql Query</th>
      <th>Views Component</th>
    <td>SELECT n.title, u.name</td>
    <td>FROM {node} n  base table</td>
    <td>view type</td>
    <td>INNER JOIN {users} u ON n.uid = u.uid</td>
    <td>WHERE n.status = 1</td>
    <td>AND u.uid = arg(1)</td>
    <td>ORDER BY n.changed DESC</td>