<?php

/**
 * The standard render pipeline for a Panels display object.
 *
 * Given a fully-loaded panels_display object, this class will turn its
 * combination of layout, panes, and styles into HTML, invoking caching
 * appropriately along the way. Interacting with the renderer externally is
 * very simple - just pass it the display object and call the render() method:
 *
 * @code
 *   // given that $display is a fully loaded Panels display object
 *   $renderer = panels_get_renderer_handler('standard', $display)
 *   $html_output = $renderer->render();
 * @endcode
 *
 * Internally, the render pipeline is divided into two phases, prepare and
 * render:
 *   - The prepare phase transforms the skeletal data on the provided
 *     display object into a structure that is expected by the render phase.
 *     It is divided into a series of discrete sub-methods and operates
 *     primarily by passing parameters, all with the intention of making
 *     subclassing easier.
 *   - The render phase relies primarily on data stored in the renderer object's
 *     properties, presumably set in the prepare phase. It iterates through the
 *     rendering of each pane, pane styling, placement in panel regions, region
 *     styling, and finally the arrangement of rendered regions in the layout.
 *     Caching, if in use, is triggered per pane, or on the entire display.
 *
 * In short: prepare builds conf, render renders conf. Subclasses should respect
 * this separation of responsibilities by adhering to these loose guidelines,
 * given a loaded display object:
 *   - If your renderer needs to modify the datastructure representing what is
 *     to be rendered (panes and their conf, styles, caching, etc.), it should
 *     use the prepare phase.
 *   - If your renderer needs to modify the manner in which that renderable
 *     datastructure data is rendered, it should use the render phase.
 *
 * In the vast majority of use cases, this standard renderer will be sufficient
 * and need not be switched out/subclassed; style and/or layout plugins can
 * accommodate nearly every use case. If you think you might need a custom
 * renderer, consider the following criteria/examples:
 *   - Some additional markup needs to be added to EVERY SINGLE panel.
 *   - Given a full display object, just render one pane.
 *   - Show a Panels admin interface.
 *
 * The system is almost functionally identical to the old procedural approach,
 * with some exceptions (@see panels_renderer_legacy for details). The approach
 * here differs primarily in its friendliness to tweaking in subclasses.
 */
class panels_renderer_empty extends panels_renderer_standard {
  /**
   * Render all prepared panes, first by dispatching to their plugin's render
   * callback, then handing that output off to the pane's style plugin.
   *
   * @return array
   *   The array of rendered panes, keyed on pane pid.
   */
  function render_panes() {
    ctools_include('content');
    // First, render all the panes into little boxes.
    $this->rendered['panes'] = array();
    foreach ($this->prepared['panes'] as $pid => $pane) {
      $content = $this->render_pane($pane);
      if ($content) {
        $this->rendered['panes'][$pid] = $content;
      }
    }

    // Swap the "empty" pane content with the middle content.
    $replace_pane = 'right';
    $empty_pane_pid = array_pop($this->prepared['regions']['empty']['pids']);
    $is_empty = array_intersect($this->prepared['regions'][$replace_pane]['pids'], array_keys($this->rendered['panes']));
    if (!empty($is_empty)) {
      unset($this->rendered['panes'][$empty_pane_pid]);     
    }
    else {
      $this->prepared['regions'][$replace_pane]['pids'][] = $empty_pane_pid;
      $this->prepared['regions']['empty']['pids'] = array();
    }
    return $this->rendered['panes'];
  }
}