The Scenario:

This scenario works from a point of view that a drupal node-type is equivalent to a database table. This scenario uses CCK, Views and Contemplate and optionally prepopulate to achieve its results. There are other scenarios and other modules that can relate and group nodes and node-types, which are not addressed within.

There exists a node-type: "type_a" which acts as the ONE table. This "type_a" node-type has other node-types related to it: "type_x", "type_y", "type_z" which act as the MANY tables (this scenario can be used with as many related node-types as needed). It is assumed that you understand that "type_a", "type_x", "type_y", "type_z" are generic names that you would replace with your own node-type names.

On a node-type "type_a" page, I would like to display a simple list (a View) of the related node-types to the node in question. Before this list (View) is displayed, I need to display several fields from node-type "node_a". I want tabbed navigation to appear such that there is an "All" tab, a "Type X" tab, a "Type Y" tab, and a "Type Z" tab, and depending on the users choice, the list (View) of related node-types displays only those node-types. In addition I need a simple "title" search mechanism for the related-nodes. And (optionally) I would like to have an "Add New" link for authorized users to create new a new node ("type_x", "type_y" or "type_z") with "type-a" already filled in.

Sorry for the long description of the scenario, but if one or all of these things is something you might need, then read on.

To implement this scenario, will require some HTML and PHP knowledge, and Clean URLs need to be turned on.

The Set-Up:

The Node Types:

The node-types (tables) are related via CCK's node-reference field type. This is important. You must first create the parent node-type "type_a" and after that create the child node-types "type_x","type_y", and "type_z". These three will have a node-reference field type, limited to "type_a" nodes. CCK is rather complex, and allows inserting existing fields into node-types. This example requires that the 3 related node-types use the same node-reference field. Of the 3 related node-types, create "type_x" first, add a new field - go to the "Create new field" section choose node-reference field type, you can name it what you like, but for examples sake, name it "parent_type_a", and fill in all the other options as required. When creating node-types "type_y" and "type_z" add a new field, go to the "Add existing field" section and choose the field "parent_type_a" that you created with node-type "type_x". Now you should have "type_x", "type_y", and "type_z" all with a common node-reference type field "parent_type_a". To verify, go to the main field list at admin/content/types/fields in the "Field name" column you should see "parent_type_a", in the "Field type" column you should see "nodereference" and in the "Used in" column you should see "type_x, type_y, type_z"

Assuming you have your node-types set-up, you should add some data into your system before moving on too far. Note down the node's nid value of a few of your node-type "type_a" nodes as they will be needed below for some testing.

The View:

Create a new View. You can name the view what ever you like in this example it will be referred to as "view_type_a_children"

Page:

• Provide Page View: checked
• URL: for testing purposes, use the same value used for name: "view_type_a_children"
• Type: Table View

Table:

• Your view needs to provide common information about each of the related node-types (x, y and z). Common meaning that all the related node-types can display the information - such as "Title", "Author", "Created" or "Updated", any field that starts with "Node: " should be fine.
• I have only done this with a view type of "Table View", but the other view types should work also.

Arguments:

• Add "Node Reference: Type A (parent_type_a)", set "Default" to "Return Page Not Found"
• Add "Node Type", set "Default" to "Display All Values"

Filters:

• Add "Node: Published", set "Operator" to "Equals", "Value" to "Yes"
• Add "Node: Title", set "Operator" to "Contains", "Value" to (leave blank)

Save your view, of course, and do a little testing. You should be able to look at your view via it's URL "view_type_a_children" The page should say "Page Not Found". In the URL after "view_type_a_children" type in "/" and then one of your "type_a" node nids (example: view_type_a_children/14). The page should now display a list of all related nodes that are related to the nid you used. In the URL after "view_type_a_children" type in "/" node nid "/" and "type_x" (example: view_type_a_children/14/type_x). The page should now display a list of only "type_x" nodes that are related to the nid you used.

Contemplate:

Assuming the above tasks are set up and working, now we move into adjusting the node page output. This example uses the contemplate module, but in theory this could be addressed in your themes template files. This is now where you need some PHP and HTML knowledge

A word of caution regarding Contemplate. Sometimes some bad PHP code we may use (we all mistakes) will disallow you from getting into the edit template form. If that happens, the only way I've discovered to fix the problem is to go into the database and remove the data. Contemplate stores the template infomation in a table named "contemplate" - one row for each node-type that contemplate has been used with. You will need to delete the row (or fix it) for your node-type "type_a" If you are not confortable with that, I don't know that I would recommend going any further.

Another word of advice, don't write your code in the form's text-area box. Write your code in your favorite PHP or text editor and then copy and paste the code into the form.

While I am no expert, it appears that when using contemplate it overrides most of the output that maybe set up elsewhere, so you need to define the full output you want, so while this gives you a lot of control, it can sometimes take a while to get set up.

For each of your CCK fields the "standard" format follows (where {YOUR_FIELD_NAME} is your actual field's name)

<div class="field field-type-text field-field-{YOUR_FIELD_NAME}">
  <h3 class="field-label">{YOUR LABEL}</h3>
  <div class="field-items">
    <?php foreach ((array)$field_{YOUR_FIELD_NAME} as $item) { ?>
      <div class="field-item"><?php print $item['view'] ?></div>
    <?php } ?>
  </div>
</div>

You can arrange your fields in whatever order you want. You can use whatever HTML you like. You can define your own classes that can then be referrenced in your style sheet. It gives you almost complete control over what is output. If you get confused on field names you can use the "Variables" list. And if you don't like the results or are having trouble, you can always delete the template.

The Template - The Implementation

In this example, I will only be talking about the node-type template for the Body (not the Teaser nor the RSS), and I will just indicate "template" to mean that.

Step 1:

The scenario says "Before the list (View) is displayed, I need to display several fields from node-type 'node_a'."

In my template I include code as noted above in the CCK Overview, arranging those fields accordingly.

Test this, make sure your node page looks how you want before moving on
(go to node/x : x = nid of a "type_a" node).

Step 2:

The scenario says: "I would like to display a simple list (a View) of the related node-types to the node in question"

This requires inserting a view into the page. This topic is disucussed in detail in the Views Documentation section at Inserting Views

What we need

• name of the view: "view_type_a_children"
• the value of the "type_a" node's nid: stored in the variable $node->nid

The code (this comes after the code you created in Step 1, and should be enclosed in the PHP tags (<?php and ?>)

// load view 
// using the views_get_view() function we can "load" a view into a local variable: $view
$view = views_get_view('view_type_a_children');

// once loaded we can adjust some of the parameters of the view
// one of the views arguments, if you remember, is "Node Reference: Type A (parent_type_a)"
// we can pass a specific value to the view, for this we want to pass the value of the "type_a" node's nid ($node->nid)

// argument values are passed via a PHP array so we need
$view_args[] = $node->nid;

// we are now ready to "build" and print out the view
// for this we use the views_build_view() function
// the last 2 values: "TRUE" and "20" allow us to have the list paged at 20 rows
print views_build_view('embed', $view, $view_args, TRUE, 20);

Test this, you should see the node and a list of all related nodes beneath it. Make sure this is working before moving on
(go to node/x : x = nid of a "type_a" node).

Step 3:

The scenario says: "I want tabbed navigation to appear such that there is an "All" tab, a "Type X" tab, a "Type Y" tab, and a "Type Z" tab, and depending on the users choice, the list (View) of related node-types displays only those node-types."

Yikes, so demanding...

Let's break this down into
A: create ability to display nodes of all types or nodes of a specific type
B: create links for the options (links will be formatted as tabs)

Step 3-A:

The ability to display related nodes of all types or related nodes of a specific type, already exists, remember from our view, the second argument was "Node Type", we need to pass this "second" argument value to the $view_arg array.

from the code above, (this code gives us the "All" option) we used

// once loaded we can adjust some of the parameters of the view
// one of the views arguments, if you remember, is "Node Reference: Type A (parent_type_a)"
// we can pass a specific value to the view, for this we want to pass the value of the "type_a" node's nid ($node->nid)

// argument values are passed via a PHP array so we need
$view_args[] = $node->nid;

We just need to add one line of code, at the bottom, to put the node-type into the arguments

$view_args[] = {NODE-TYPE};

We have 3 different node types so, if your following...

// for node-type "type_x" use
$view_args[] = 'type_x';

// for node-type "type_y" use
$view_args[] = 'type_y';

// for node-type "type_z" use
$view_args[] = 'type_z';

How do we know which type the user wants to see?

First, we need to talk a little about Drupal paths (who knew you had to know so much...)

Hopefully by now you understand that in your URL "node/x" (where x = the nid of a node) displays the node page. You can mask it using the Path module, but even so "node/x" is still used by drupal, in the background. Maybe you have noticed that if you go to edit a node the path is "node/x/edit". If you have the book module enabled and you go to outline a node, the path is "node/x/outline". If you have statistics module enabled and you go to track, the path is "node/x/track"

Drupal divides the path into multiple values using the "/" character as the separator. Drupal interprets this path and then looks for instructions to know what to display. If Drupal looks and doesn't find instuctions for what to do, then it lops off the last value and looks again for instructions.

If you go to "node/x/hello" Drupal looks for "node/x/hello" instuctions, does not find any, then looks for "node/x" instructions which informs drupal to display the node page. If you go to "node/x/hello/my/name/is/john" you make Drupal look 6 times for something to do until it finally does.

I noted that Drupal divides the path into multiple values using the "/" character as the separator. Drupal allows you to extract those values by using the "arg() function. Starting with 0, you can find the value of each of the "args"

With "node/15"
- arg(0) = node
- arg(1) = 15
With "node/15/edit"
- arg(0) = node
- arg(1) = 15
- arg(2) = edit
With "node/15/hello"
- arg(0) = node
- arg(1) = 15
- arg(2) = hello

So now that we understand a little about Drupal paths, we can use this fuctionality to our benefit.

In our example with "node/x"
- arg(0) = node
- arg(1) = x
Our page is output, and currently our Views code with "view_type_a_children" produces all node-types

We could pass a node type through arg(2) to indicate the node type

So with "node/15/type_x"
- arg(0) = node
- arg(1) = 15
- arg(2) = type_x
Drupal would check for instructions on how to handle "node/15/type_x", not find any, would look for "node/15" instuctions which would show the node page

So if there is an arg(2) that will be our signal that the we should display a particular node-type. If arg(2) is blank that will be our signal to show all node-types.

So to this section of code...

// once loaded we can adjust some of the parameters of the view
// one of the views arguments, if you remember, is "Node Reference: Type A (parent_type_a)"
// we can pass a specific value to the view, for this we want to pass the value of the "type_a" node's nid ($node->nid)

// argument values are passed via a PHP array so we need
$view_args[] = $node->nid;

we add a simple if/then (I've also changed the comments for clarity)

// once loaded we can adjust some of the parameters of the view
// one of the views arguments, if you remember, is "Node Reference: Type A (parent_type_a)"

// argument values are passed via a PHP array so we need
// the first arg we need to pass is the value of the "type_a" node's nid ($node->nid)
$view_args[] = $node->nid;
// the second arg we need to pass is the node type indicated by arg(2)
// if there is no arg(2) then "Show All" is assumed
if (arg(2)) {
  $view_args[] = arg(2);
}

We're not quite finished with this step - we still need to create the links, but you should be able to test this
With "node/x" you should see all related nodes
With "node/x/type_x" you should only see related nodes that are node-type "type_x"
With "node/x/hello" you should see no nodes at all, unless you have a related node-type named "hello"

Step 3-B: create links for the options (links will be formatted as tabs)

Links are actually easy enough to create just with simple HTML, we just need to know the node's nid which we've already used, it's $node->nid. The href value is "http://www.example.com/node/{nid}/{node-type}"

As a first step we will put them in a simple unordered list, you should of course change www.example.com/ to your domain. Note this is HTML with PHP used just to print the $node->nid, so this section should not be enclosed it PHP tags. This section should come just before the Views code we did above.

<ul>
<li><a href="http://www.example.com/node/<?php print $node->nid ?>">Show All</a></li>
<li><a href="http://www.example.com/node/<?php print $node->nid ?>/type_x">Show Type X</a></li>
<li><a href="http://www.example.com/node/<?php print $node->nid ?>/type_y">Show Type Y</a></li>
<li><a href="http://www.example.com/node/<?php print $node->nid ?>/type_z">Show Type Z</a></li>
</ul>

Now we need to format the links as tabs.

I haven't discovered a function to just wrap my links as tabs - the various theme funtions make calls to the menu system, and since these aren't real menu items, that's not going to work...

So the HTML you need should copy your themes method of outputting tabs. You could also use your own classes and create some CSS to make them look however you want. In this example I'll just use the markup provided by the default garland theme.

One of the tabs needs to be set as "active" so we have to if/then each of the tabs
Again HTML code, so this section should not be enclosed it PHP tags

<div id="tabs-wrapper" class="clear-block">
<ul class="tabs primary">
<li<?php print (arg(2) ? '' : ' class="active">'?>><a href="http://www.example.com/node/<?php print $node->nid ?>">Show All</a></li>
<li<?php print (arg(2) == 'type_x' ? ' class="active" : ''>'?>><a href="http://www.example.com/node/<?php print $node->nid ?>/type_x">Show Type X</a></li>
<li<?php print (arg(2) == 'type_y' ? ' class="active" : ''>'?>><a href="http://www.example.com/node/<?php print $node->nid ?>/type_y">Show Type Y</a></li>
<li<?php print (arg(2) == 'type_z' ? ' class="active" : ''>'?>><a href="http://www.example.com/node/<?php print $node->nid ?>/type_z">Show Type Z</a></li>
</ul>
</div>

Here's the same output written all in PHP, and should be enclosed it PHP tags
Not sure which one is easier to to read.

// print view navigation tabs
print '<div id="tabs-wrapper" class="clear-block">';
print '<ul class="tabs primary">';
print (arg(2) ? '' : '<li class="active">') .'<a href="http://www.example.com/node/'. $node->nid .'">Show All</a></li>';
print (arg(2) == 'type_x'  ? '<li class="active">' : '<li>') .'<a href="http://www.example.com/node/'. $node->nid .'/type_x">Show Type X</a></li>';
print (arg(2) == 'type_y'  ? '<li class="active">' : '<li>') .'<a href="http://www.example.com/node/'. $node->nid .'/type_y">Show Type Y</a></li>';
print (arg(2) == 'type_z'  ? '<li class="active">' : '<li>') .'<a href="http://www.example.com/node/'. $node->nid .'/type_z">Show Type Z</a></li>';
print '</ul>';
print '</div>';

Give this a test, it should all be working the way you think.
With "node/x" you should see all related nodes, the "Show All" tab should be active
With "node/x/type_x" you should only see related nodes that are node-type "type_x" the "Show Type X" tab should be active
With "node/x/hello" you should see no nodes at all, unless you have a related node-type named "hello", no tabs should be active

Step 4:
The scenario says: "In addition I need a simple "title" search mechanism for the related-nodes."

If you are familiar with Views you can do an exposed filter for this. If we had done that with our "view_type_a_children" we would see a simple text box and a submit button. The underlying form though has an action="http://www.example.com/view_type_a_childern/x" Because of the action, if we had the exposed filter, then the user would be redirected to the views URL which is not what we want.

<form action="http://www.example.com/view_type_a_childern/x"  method="get" id="views-filters">
<div>
  <table>
    <thead>
      <tr>
        <th>Title</th><th></th>
      </tr>
    </thead>
    <tbody>
      <tr class="odd">
        <td>
          <div class="form-item">
            <input type="text" maxlength="255" name="filter0" id="edit-filter0"  size="10" value="" class="form-text" />
          </div>
        </td>
        <td>
          <input type="submit" id="edit-submit" value="Submit"  class="form-submit" />
        </td>
      </tr>
    </tbody>
  </table>
</div>
</form>

I have not seen a place to over-ride that, so this is what I chose to do. I copied the code output by the Views Filter and put it into my template, I, of course, removed the action="-blah" part so the first line becomes

<form method="get" id="views-filters">

But, there is a little more that needs to be changed, and this was the part that frustrated me the most when I was trying to figure it out.

First I wanted to get the value submitted by the user to appear in the text box.
That part is easy enough, change the input box HTML to

<input type="text" maxlength="255" name="filter0" id="edit-filter0"  size="10" value="<?php print $_GET['filter0'] ?>" class="form-text" />

Then the Views code needs to be adjusted to take into account the filter value (if any)

This you'll remember from Section 2 is the last part of code used to print out the view

// we are now ready to "build" and print out the view
// for this we use the views_build_view() function
// the last 2 values: "TRUE" and "20" allow us to have the list paged at 20 rows
print views_build_view('embed', $view, $view_args, TRUE, 20);

before that section we need to add

// if user submitted a filter value, apply it to the view
if ($_GET['filter0'] != '') {
	$view->filter[1][value] = $_GET['filter0'];
}

The part that confused me for the longest time was the number associated with the filter
If you look in the HTML code used with the form its filter 0
If you look at the PHP that applies the filter to the view the filter is 1

What's going on....

Well, the numbering I wrongly assumed was somehow related. The HTML form, starting with 0 assigns a value to each exposed filter. If only the Node Title filter was exposed, then that is filter 0. The PHP code to assign the value to the actual view filter numbers it as 1. If you remember, when we set up the view our 1st filter (filter 0) was "Node: Published equals Yes" and the 2nd filter (filter 1) was "Node: Title contains (blank)"

So when using PHP to apply the filter, make sure you are applying a value to the right filter. I ended up being so confused that I changed the name of the input box to match the actual views filter.

So I really rendered the input box with the followiwng HTML to and changed the variable from $filter to $filter1
HTML changed to:

<input type="text" maxlength="255" name="filter1" id="edit-filter1"  size="10" value="<?php print $_GET['filter1'] ?>" class="form-text" />

PHP Code

// if user submitted a filter value, apply it to the view
if ($_GET['filter1'] != '') {
	$view->filter[1][value] = $_GET['filter1'];
}

Section 5 (optionally):

The scenario says: "And (optionally) I would like to have an 'Add New' link for authorized users to create new a new node ("type_x", "type_y" or "type_z") with "type-a" already filled in."

This section can be achieved by the prepopulate module, but it can be frustrating to figure out.

The first thing to do is figure our the querystring you need to make prepopulate work to insert the "type_a" nid into a new "type_x"

There are various combinations you should try are

Select List Option:
x = nid, example: "10"
- node/add/type_x?edit[field_type_a_parent][nid]=x
- node/add/type_x?edit[field_type_a_parent][nids]=x
w/ field in a group ({GROUP-NAME} = the group name)
- node/add/type_x?edit[group_{GROUP-NAME}][field_type_a_parent][nid]=x
- node/add/type_x?edit[group_{GROUP-NAME}][field_type_a_parent][nids]=x

Autocomplete Option:
x = Title [nid:nid], example: "Drupal Rocks! [nid:10]"
- node/add/type_x?edit[field_type_a_parent][0][node_name]=x
w/ field in a group ({GROUP-NAME} = the group name)
- node/add/type_x?edit[group_{GROUP-NAME}][field_type_a_parent][0][node_name]=x

That's the most frustrating part, but once you figure it out, you're good to go

The link will only appear when the user is looking at a specific type, and not on the "Show All" tab, and only if the user has permission to create such node types. You will need to go to your admin/user/access page and note down the name of the create permission for each your related node types. If you created them using Drupals interface, chances are the format is "create {node-type} content"

This code is PHP and should appear in PHP tags. While it can be placed where ever you like, for examples sake I suggest between the your links and your view.

// perform switch statement on arg(2) to see if user has selected a type
// if so check for "create" permission of user
// if user has permission, write link...
switch (arg(2)) {
  case 'type_x':
      if (user_access('create type_x content')) {
        // this example shows the link with a simple nid value
        print '<a href="http://www.example.com/node/add/type-x?edit[field_type_a_parent][nids]='. $node->nid .'>Add New Type X</a>';
      }
    break;
  case 'type_y':
      if (user_access('create type_y content')) {
        // this example shows the link with an autocomplete value
        print '<a href="http://www.example.com/node/add/type-y?edit[field_type_a_parent][0][node_name]='. $node->title .' [nid:' .$node->nid .']>Add New Type Y</a>';
      }
    break;
  case 'type_z':
      if (user_access('create type_z content')) {
        // this example is the same as type_x
        print '<a href="http://www.example.com/node/add/type-z?edit[field_type_a_parent][nids]='. $node->nid .'>Add New Type Z</a>';
      }    
    break;
}

You should now test this to see if the "add new" links are working properly.

Well that's it. Hope you found it useful in some way.

The Review

One last thing, this code can be condensed, and you'll know what I mean if you are a PHP coder. I kept each of the distinct tasks modularized so that people could leave out certain sections without having to make a bunch of adjustments elsewhere. Or just use the section they needed.

The Code

Here though is all the code for the entire template in a more natural order

<!-- Step 1:  putting fields in the top of your node page -->
<!-- you can arrange your fields however you like, this is just the default coding used -->
<div class="field field-type-text field-field-{YOUR_FIELD_NAME}">
  <h3 class="field-label">{YOUR LABEL}</h3>
  <div class="field-items">
    <?php foreach ((array)$field_{YOUR_FIELD_NAME} as $item) { ?>
      <div class="field-item"><?php print $item['view'] ?></div>
    <?php } ?>
  </div>
</div>

<!-- Step 3:  tabbed navigation to allow users to select node-type to view -->
<?php
// print view navigation tabs
print '<div id="tabs-wrapper" class="clear-block">';
print '<ul class="tabs primary">';
print (arg(2) ? '' : '<li class="active">') .'<a href="http://www.example.com/node/'. $node->nid .'">Show All</a></li>';
print (arg(2) == 'type_x'  ? '<li class="active">' : '<li>') .'<a href="http://www.example.com/node/'. $node->nid .'/type_x">Show Type X</a></li>';
print (arg(2) == 'type_y'  ? '<li class="active">' : '<li>') .'<a href="http://www.example.com/node/'. $node->nid .'/type_y">Show Type Y</a></li>';
print (arg(2) == 'type_z'  ? '<li class="active">' : '<li>') .'<a href="http://www.example.com/node/'. $node->nid .'/type_z">Show Type Z</a></li>';
print '</ul>';
print '</div>';
?>

<!-- Step 4:  from to allowing filtering by node title -->
<form method="get" id="views-filters">
<div><table>
<thead><tr><th>Title</th><th></th></tr></thead>
<tbody><tr class="odd">
<td><div class="form-item">
<input type="text" maxlength="255" name="filter1" id="edit-filter1"  size="10" value="<?php print $_GET['filter1'] ?>" class="form-text" />
</div></td>
<td><input type="submit" id="edit-submit" value="Submit"  class="form-submit" /></td>
</tr></tbody>
</table></div>
</form>

<!-- Step 5:  "add new" links -->
<?php
// perform switch statement on arg(2) to see if user has selected a type
// if so check for "create" permission of user
// if user has permission, write link...
switch (arg(2)) {
  case 'type_x':
      if (user_access('create type_x content')) {
        // this example shows the link with a simple nid value
        print '<a href="http://www.example.com/node/add/type-x?edit[field_type_a_parent][nids]='. $node->nid .'>Add New Type X</a>';
      }
    break;
  case 'type_y':
      if (user_access('create type_y content')) {
        // this example shows the link with an autocomplete value
        print '<a href="http://www.example.com/node/add/type-y?edit[field_type_a_parent][0][node_name]='. $node->title .' [nid:' .$node->nid .']>Add New Type Y</a>';
      }
    break;
  case 'type_z':
      if (user_access('create type_z content')) {
        // this example is the same as type_x
        print '<a href="http://www.example.com/node/add/type-z?edit[field_type_a_parent][nids]='. $node->nid .'>Add New Type Z</a>';
      }    
    break;
}
?>


<!-- Step 2:  inserting the view into the page -->
<!-- incorporating Step 3 dealing with node-type and Step 4 dealing with Title filter -->
<?php 
// load view 
// using the views_get_view() function we can "load" a view into a local variable: $view
$view = views_get_view('view_type_a_children');

// once loaded we can adjust some of the parameters of the view
// one of the views arguments, if you remember, is "Node Reference: Type A (parent_type_a)"
// we can pass a specific value to the view, for this we want to pass the value of the "type_a" node's nid ($node->nid)

// argument values are passed via a PHP array so we need
// the first arg we need to pass is the value of the "type_a" node's nid ($node->nid)
$view_args[] = $node->nid;
// the second arg we need to pass is the node type indicated by arg(2)
// if there is no arg(2) then "Show All" is assumed
if (arg(2)) {
  $view_args[] = arg(2);
}

// if user submitted a filter value, apply it to the view
if ($_GET['filter1'] != '') {
	$view->filter[1][value] = $_GET['filter1'];
}

// we are now ready to "build" and print out the view
// for this we use the views_build_view() function
// the last 2 values: "TRUE" and "20" allow us to have the list paged at 20 rows
print views_build_view('embed', $view, $view_args, TRUE, 20);
?>

The End

In terms of comments...
If there is an error in the code, or a section is completely unclear, please comment on that and it can be fixed in the post. I have no doubt that I've dropped several periods and missed some parentheses (and I appologize now for that).

If you want to ask a related how-to, I think that would best be done in the forums, this post could get cluttered pretty quickly. Questions like, how do I use a different view for "type_y" nodes, or how do I get a vocabulary->term selector, can a calendar view be used, will probably get answered more quickly in the forums. Once you get the answer you are looking for then see the note below!

If you do something similar, please share, think about adding a book page to this post and outline what you were looking to do and how you accomplished it.