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 Node view type), content revisions (a Node revisions view type) or users (a User view type). A view may be restricted to members of specific user roles, and may be added, edited or deleted at the views administration page.
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:
Fields, or the individual pieces of data being displayed. Adding the fields Node: Title, Node: Type, and Node: Post date to a node view, for example, includes the title, content type and creation date in the displayed results
Relationships, or information about how data elements relate to one another. If relationship data is available, like that provided by a CCK nodereference field, items from a related node may be included in the view
Arguments, or additional parameters that dynamically refine the view results, passed as part of the path. Adding an argument of Node: Type 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 "http://www.example.com/content/page" displays all posts of the type "page", the path "http://www.example.com/content/story" displays all posts of the type "story", and "http://www.example.com/content" displays all posts regardless of type)
Sort criteria, which determine the order of items displayed in the view results. Adding the sort criteria Node: Post date (in descending order) to a node view, for example, sorts the displayed posts in descending order by creation date
Filters, which limit items displayed in the results. Adding the filter Node: Published (and setting it equal to "Published") to a node view, for example, prevents unpublished items from being displayed
Displays, 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 page display, which gives a view a path and allows it to be the primary content of a page, or the block display which allows it to appear as secondary content on other pages.
Header, which allow you to add by default one or more text area above the views output.
Footer, which allow you to add by default one or more text area beneath the views output.
The Emtpy Text content will be displayed, when you choose in the Arguments Section "Action to take if argument is not present" the option "Display empty text".
Parallels between the components in the Views interface and an sql query: