Hour 23. Using View Arguments and Modifying Built-In Pages

What You’ll Learn in This Hour:

• How to Create Dynamic Views

• How to Create and Set Arguments for Dynamic Views

• How to Make the Built-In Pages More Useful in Your Environment

• How to Use User and Node Reference Fields

Introduction

This hour builds on views, panels, and pages to show you how to build dynamic content views and modify pages—including Drupal’s built-in pages. You can use and reuse the components and complexity that you have now mastered to help you build large and complex sites that are, nevertheless, simple for end users, as well as easy for you and your colleagues to design, build, and maintain. In addition, you will see how to move beyond websites to incorporate content and database management features that take advantage of Drupal.

Go To

REVIEW HOUR 14, “WORKING WITH VIEWS,” P. 237 AND HOUR 20, “LAYING OUT PANELS AND PAGES,” P. 337.

Constructing a Dynamic Page

In Hour 14, you saw how to construct a view that retrieves and displays data from the database. You saw not only how to hard-code the selection criteria, but also how to expose the interface, as shown in Figure 23.1.

Figure 23.1. Allow users to select the data to display in a view.

image

In this hour, you will see how to construct a dynamic view—one in which the data is selected based on an argument that is passed in as part of the URL. Figure 23.2 shows a dynamic page in which the data is specified in the address rather than being hard-coded in the view or set by the user.

Figure 23.2. Create a dynamic page.

image

Understanding Dynamic Views

Automating the process of data selection can make things much easier for your users. If nothing else, it eliminates an unnecessary step in which they have to go to the page that will display the data, choose the data, and then wait for the page to be refreshed.

In addition to simplifying the user interface, the idea of using arguments in the path gives you, the site designer and implementer, much less work to do. You lay out the view as you want it to be shown, regardless of the content that is displayed. Then, to show one set of data or another, you vary the arguments. For example, assume that the view is named myview, and that it can show information from data identified by a taxonomy term. That term can be used to select data, and thus, after you have built myview, you can use any of the following Drupal paths:

myview/personnel

myview/news

myview/press-releases

myview/documents-public

and so forth. Note that it is common to use hyphens to replace spaces in arguments for these pages.

Arguments can be used for more than just selecting data. For example, you can specify that one argument is used as the title. It does not matter which one: it is up to you to associate each argument with its use. As far as Drupal is concerned, these two arguments could be functionally equivalent:

myview/documents/public/

myview/public/documents

By the Way: URL Conventions

Drupal users and the documentation are inconsistent on terminology in this area, so here is how this book handles these fragments of URLs. First, in this hour, we assume that you have installed and enabled Pathauto as described previously in Hour 6, “Managing URLs: Cleaning, Redirects, and PathAuto,” p. 87. As a reminder, addresses on your website are provided as partial URLs. Thus, the first partial URL shown in the previous section actually resolves to yourwebsite.com/myview/personnel. Drupal will disassemble that into a path (myview) and an argument to that path (personnel). Multiple arguments can exist for a single path so that the fourth example would resolve to two arguments: documents and public.

Creating a Dynamic View

Building a dynamic view has just a few variations from building a static view. After the view has been created, you can create a page variant so that your page will be complete.

This example is built on a section of the Y2KX.net site that has been shown previously. For now, all that is important to know is that there is a taxonomy vocabulary called Site Tags. Its identification and content settings are shown in Figure 23.3. (Whether forum topics are included as requiring a tag in this vocabulary depends on your particular data.)

Figure 23.3. Use a new or existing vocabulary to tag your site’s data.

image

The settings shown in Figure 23.4 mean that you can rely on every node in every major content type having at least one Site Tags tag. This is not required at all for this example to work. However, if you will be relying on taxonomy tags to retrieve data, you are better off if you know that the data has been properly tagged. (In other words, it is not only nice to have those tags, it is essential. Without them, data can be lost forever.)

Figure 23.4. Your site is more robust if at least one tag is required for each node.

image

Modifying a Built-In Page

You can use pages and panels to modify built-in pages. You will recognize some of the interface from the view editor—in particular, the notion of pages that are in code and that can have variants you create. This enables you to override built-in pages. The example shown here lets you override the basic Create Content page.

Why would you do this? One reason is that you might like it laid out differently for your use or the use of your colleagues. But, particularly with a site that has extensive user contributions (or contributions from advanced users), the data entry pages may need tweaking to make them more specific. You may want your logo on them, for one trivial point. You can relabel fields, but by modifying the entire page structure, you have the ability to make it fit into a corporate look and feel. In any event, it is worth experimenting with; you already know the basics (and a lot more!).

Go to Administer, Site Building, Pages (admin/build/pages), as shown in Figure 23.18. You will see any pages you have created there. You will also find some built-in pages that, by default, are disabled.

Figure 23.18. See existing pages.

image

Edit the first page—node_edit, the page used when adding or editing a node—by clicking Edit. After you click Edit, you will be on the summary page for that page, as shown in Figure 23.19. Whether or not variants are shown depends on your Drupal installation and settings. You will add a new one in the next section.

Figure 23.19. See the summary.

image

Click Add a New Variant at the bottom. The page shown in Figure 23.20 opens.

Figure 23.20. Add a new variant.

image

Set the page title if you want. Then, click Create Variant to open the now familiar page shown in Figure 23.21. You choose the layout for your variant.

Figure 23.21. Choose a layout.

image

After you choose your layout, click Continue. As you can see in Figure 23.22, you are back in the world of pages and panels. The only difference now is that you have some additional panels you can add. Click Add Content, as shown in Figure 23.22.

Figure 23.22. Add content.

image

You have new categories of content that you can add in addition to the content types you have seen before. Figure 23.23 shows the Form content choices. These are the components of the Add Node form.

Figure 23.23. Choose from new components.

image

Figure 23.24 and Figure 23.25 show the top and bottom of a Create Content page created in this way. (The basic layout is the Flexible layout.)

Figure 23.24. Create content: top.

image

Figure 23.25. Create content: bottom.

image

Using Node Reference and User Reference Fields

The emphasis in this book has been on developing websites with Drupal because that is how many people think of using it. But, remember that Drupal is a Content Management System (CMS), and in some ways, its web capabilities are extensions of that core. You can use Drupal to build powerful database solutions that, subject to your security settings, might be visible on the web to the public or visible only to a limited group—perhaps certain users or perhaps only people on your intranet.

This section describes how you can combine Drupal core functionality and built-in modules to produce a solution to a very common problem: project tracking. The example shown here is specific, but it has a multitude of real-world parallels in various fields.

The data structure is simple:

Projects are the focus of the system. They will be a custom content type.

• Each project is associated with one client. If you have a multi-client project, most organizations create a new internal “client” that is a combination of the two. A client can have many projects.

• A coordinator manages the project and keeps it on track. A coordinator can have many projects, but each project has only one coordinator. In a law firm, this might be a partner; in a marketing company, the coordinator might be a traffic manager. Whether the coordinator is the client contact varies depending on how the company is organized and the work that it does.

• Projects go through multiple phases; the coordinator moves a project from one phase to another or sends it back for a redo. In some cases, a project has only a single phase.

The Drupal implementation will use two CCK field types: node references and user references. These differ from the fields that contain data, such as text. They contain references to other nodes or to users. Drupal makes it easy to set these up, as you will see in this example.

You can build sophisticated views to display projects and their status, but just using the basic Drupal interface with no customization, you can work with the project tracking data you will develop. Figure 23.26 shows what a project node will look like.

Figure 23.26. Build a project tracking system.

image

The project node is a custom content type that has three fields added: status, client, and coordinator. Status is a text field, client is a node reference field, and coordinator is a user reference field. In the default display shown in Figure 23.25 both client and coordinator are displayed as links to the appropriate data.

Figure 23.27 shows the revision log for a project. This requires absolutely no work on your part other than entering the data in the log for a new revision. Revisions are built into Drupal.

Figure 23.27. Drupal revisions manage project phases.

image

As you see in Figure 23.28, Drupal automatically maintains the link between coordinator and projects. Figure 23.28, all the projects for a given coordinator are shown in the Related Content area of the user’s profile, and they are presented as links on which you can click.

Figure 23.28. Drupal tracks projects for a coordinator.

image

Summary

You have seen how to build views that are driven by arguments placed in their URLs. One view can serve up any number of different permutations of data without changing any links or code. You have also seen how to extend the new Drupal interfaces into the data entry area.

Q&A

Q. A friend says it is easier to write PHP code to retrieve custom data from Drupal. Is she right? Should I start studying?

A. Most of what you can do in Drupal can be done in code (it has to be able to be done in code because that is how Drupal implements it). For experienced programmers, it often seems as if writing code is the fastest and most efficient way to get the job done. One of Drupal’s great strengths is exposing its power through a graphical user interface rather than a PHP interface. And a further problem arises: The code that you write today will undoubtedly need some maintenance and modification over the years. Going the code route locks you into code forever. Working with Drupal’s new tools, such as node and user reference fields, views, pages, and panels, locks you into...a graphical user interface.

Q. I showed my users how easy it is to create views. Now, they want customized views for each department, and they all display the same data. What do I do?

A. Creating many customized views that display the same data in different formats and combinations may seem like wasted work, but it can be useful. There may be reasons each department wants its own format. In any case, bending the technology to the wishes of the users is a good idea whenever possible.

Workshop

Quiz

1. Does the fact that a Drupal URL may have embedded arguments in it mean that it can’t be used for people outside the Drupal world?

2. Can I move the Submit button for new content to the top of the form?

3. How do I use a path to a dynamic view?

Quiz Answers

1. No. There is nothing about a URL with embedded Drupal arguments that makes it look any different from any other URL. Access is dependent on the regular Drupal security mechanism (such as logging in).

2. Yes, but make sure that you don’t run into interface issues. If you use panel pages for multicolumn input, you can make the vertical dimension of the page much less, so a Submit button at the bottom of the page is not so far off as it otherwise would be.

3. Type it into a custom block, put it in a story, or use it anywhere you want. It is a URL, plain and simple.

Activities

If you have a lot of user-created content, sit with the users to find out how they would like their data entry page to look. Gathering a focus group together can be useful. Do the same for dynamic views. Try to avoid one-on-one interviews; you will wind up with at least as many choices as people you have talked to.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.144.10.69