Home » Views Documentation » Views 1.x user documentation » Views Arguments

Defining and sending Views Arguments

My working theory on methods for defining Views Arguments.

a quick note on drupalabels : what the View-edit page calls 'Arguments' I will refer to as 'Argument Handlers' because they do stuff with the Arguments that are passed to them; the Handler is a 'function' and the Arguments are the '$variables'. I will therefore use 'Arguments' to refer to the data in the 'args' array.

Getting the right Argument to the View's Argument Handler can be tricky.
As far as I know, there are only two 'carriers' from which a View Argument Handler can get the Argument:

    1: URL (passive method)
  • As far as I can tell, Views' default (off the peg) Argument Handlers try to pick out a particular section (NID, UID, TID, etc) from the context-node's URL (eg www.site.com/node/23 ... so the NID = '23') and use this as the (first) Argument ($args[0]).
  • Every page has a URL, so there's always something for the Handler to work with. But because URLs can get messed about so much by modules and such, this method often seems (IMHO) to yield unpredictable results. Of course if you can predict exactly how your URLs are going to be structured, you only need to customise is the View's Argument Handling Code to translate the URL structure into the View's $args array structure.

      • 2: views_build_view() (active method)
  • The context-node (or module or whatever) itself specifies the Arguments (the args array) and sends it to the View when calling it, using views_build_view() as the carrier.
  • The downside is that you have to figure out where and how to insert (hack) the following php code (or similar) into the context-node, module, node.tpl.php, block, or whatever it is that calls the View into being. For example, the NID is a property of the context-node's $node_array (eg $node->nid), not the view, so we need to define the Argument within something that is part of or has access to that context-node's $node array. IMHO this method is more reliable and predictable ... in a sledgehammer sort of a way ;)
  • Calling the views_build_view function
    <?php
          global $current_view;
          $current_view->args[0]=$node->nid;
          $view1 = views_get_view('view_name');                     // change 'view_name' to the name of your view
            print (views_build_view('embed', $view1, $current_view->args, false, false)); 
    ?>

    • Feedback:
    This page is a work in progress. I will add to and edit as I get a better grasp of what's going on and why, but I hope in the meantime it may help other drupaleers struggling up the north face of Views.
    Of course if anyone has any advice, suggestions, theories, explanations or improvements; or especially if I've misunderstood something - please, please, please do jot them in a comment or contact me (JohnG) and I'll gladly incorporate them as best I can.

    ‹ Views ArgumentsupSome use cases of Arguments ›
    » Login or register to post comments

    Select different return data formats for views_build_view(..)

    Bitmaster - August 14, 2007 - 20:49

    By replacing the first parameter in the method views_build_view(..) with one listed below, you can get the return data in a variety of forms. Below is a list of parameters and their return type. This information was extracted from the source code.

    For example if you created a view to get a list of node id's and wanted those id's to be returned in the form of an array... You would chose the 'items' parameter as the first argument of the method call...

    $id_list = views_build_view('items', $view1, $current_view->args, false, false));

    'page' -- Produce output as a page, sent through theme. The only real difference between this and block is that a page uses drupal_set_title to change the page title.
    'block' -- Produce output as a block, sent through theme.
    'embed' -- Use this if you want to embed a view onto another page, and don't want any block or page specific things to happen to it.
    'result' -- return an $info array. The array contains:
    * query: The actual query ran.
    * countquery: The count query that would be run if limiting was required.
    * summary: True if an argument was missing and a summary was generated.
    * level: What level the missing argument was at.
    * result: Database object you can use db_fetch_object on.
    'items' -- return info array as above, except instead of result, items: An array of objects containing the results of the query.
    'queries' -- returns an array, summarizing the queries, but does not run them.

    Hope this helps,
    Bit

    Login or register to post comments

    Accessing nid as argument for view block

    stg11 - August 25, 2007 - 20:16

    Edwin M. Basye
    Sites That Grow

    I found http://drupal.org/node/83415 to be very helpful to access the current nid from the internal url for a view block and assigning the argument value

    the view  argument handling code for 5.x  is
    if ($view->build_type == 'block' && arg(0) == 'node' && is_numeric(arg(1))) {
      $args[0] = arg(1);
    }
    return $args;

    That way you don't have to hack the code in any module.

    I used this to place a picture gallery view block at the bottom of a group display

    Login or register to post comments
     
     

    Drupal is a registered trademark of Dries Buytaert.