views.rst 14 KB

  2. #####
  3. .. contents:: Contents
  4. :local:
  5. :depth: 1
  6. Introduction
  7. ============
  8. Elgg follows a MVC pattern and Views are the V in MVC. Views are responsible for creating the output. Generally, this will be HTML sent to a web browser, but it could also be RSS, JSON or any number of other data formats.
  9. The Views system handles everything from the layout of pages and chunks of presentation output (like a footer or a toolbar) down to individual links and form inputs. It also allows for advanced features like automatic RSS generation, a swift-to-develop mobile interface, and the alternative interfaces suggested below.
  10. Using views
  11. ===========
  12. At their most basic level, the default views are just PHP files with snippets of html. For example:
  13. .. code-block:: html
  14. <h1>Hello, World!</h1>
  15. Assuming this view is located at ``/views/default/hello.php``, we could output it like so:
  16. .. code-block:: php
  17. echo elgg_view('hello');
  18. For your convenience, Elgg comes with quite a lot of views by default. In order to keep things manageable, they are organized into subdirectories. Elgg handles this situation quite nicely. For example, our simple view might live in ``/views/default/hello/world.php``, in which case it would be called like so:
  19. .. code-block:: php
  20. echo elgg_view('hello/world');
  21. Well that's easy enough to remember! The name of the view simply reflects the location of the view in the views directory.
  22. Views as templates
  23. ==================
  24. Views would be pretty useless if they could only contain static information. Fortunately, you can pass arbitrary data to a view via the ``$vars`` array. Our ``hello/world`` view might be modified to accept a variable like so:
  25. .. code-block:: php
  26. <h1>Hello, <?php echo $vars['name']; ?>!</h1>
  27. In this case, we can pass an arbitrary name parameter to the view like so:
  28. .. code-block:: php
  29. echo elgg_view('hello/world', array('name' => 'World'));
  30. which would produce the following output:
  31. .. code-block:: html
  32. <h1>Hello, World!</h1>
  33. .. _guides/views#viewtypes:
  34. Viewtypes
  35. =========
  36. You might be wondering, "what's with the 'default' in the directory structure? Why don't we just put the ``hello/world`` view at ``/views/hello/world.php``?".
  37. Great question.
  38. This subdirectory (the one under ``/views``) determines the *viewtype* of the views below it. It's possible that you might want your Elgg site to have several sets of interface pages. For example:
  39. * Standard HTML for desktop browsing (This is the default view)
  40. * HTML optimized for Mobile devices (iPhone, Android, Blackberry, etc.)
  41. * HTML optimized Tablet devices (iPad, etc.)
  42. * RSS
  43. * Atom
  44. * JSON
  45. * etc...
  46. In Elgg, one set of these interface pages is called a *viewtype*. You can force Elgg to use a particular viewtype to render the page simply by setting the ``$view`` input variable. For example, to get an RSS version of the home page, you would access ``http://localhost/elgg/?view=rss``.
  47. You could also write a plugin to set this automatically using the ``set_input()`` function. For example, your plugin might detect that the page was accessed with an iPhone's browser string, and set the viewtype to *handheld* by calling:
  48. .. code-block:: php
  49. set_input('view', 'handheld');
  50. The plugin would presumably also supply a set of views optimized for handheld devices.
  51. .. _guides/views#altering-views-via-plugin:
  52. Altering views via plugins
  53. ==========================
  54. Without modifying Elgg's core, Elgg provides several ways to customize almost all output:
  55. * You can `override a view <#overriding-views>`_, completely changing the file used to render it.
  56. * You can `extend a view <#extending-views>`_ by prepending or appending the output of another view to it.
  57. * You can `alter a view's inputs <#altering-view-input>`_ by plugin hook.
  58. * You can `alter a view's output <#altering-view-output>`_ by plugin hook.
  59. Overriding views
  60. ----------------
  61. Via plugin you can completely replace the rendering strategy of a view provided by Elgg or another plugin. Each plugin may have its own ``/views`` directory, and within it define its own view implementations.
  62. Views in plugin directories always override views in the core directory, however, when plugins override the views of other plugins, :ref:`later plugins take precedent <admin/plugins#plugin-order>`.
  63. For example, if we wanted to customize the ``hello/world`` view to use an ``h2`` instead of an ``h1``, we could create a file at ``/mod/example/views/default/hello/world.php`` like this:
  64. .. code-block:: php
  65. <h2>Hello, <?php echo $vars['name']; ?></h2>
  66. While it is **not recommended**, one *could* alternatively force the location of a view using the ``set_view_location`` function:
  67. .. code-block:: php
  68. set_view_location($view_name, $full_path_to_view_file);
  69. Again, the best way to override views is to place them in the appropriate place in the views hierarchy.
  70. .. note::
  71. When considering long-term maintenance, overriding views in the core and bundled plugins has a cost: Upgrades may bring changes in views, and if you have overridden them, you will not get those changes. You may instead want to :ref:`alter the input <guides/views#altering-view-input>` or the :ref:`the output <guides/views#altering-view-output>` of the view via plugin hooks.
  72. .. note::
  73. Elgg caches view locations. This means that you should disable the system cache while working with views. When you install the changes to a production environment you mush flush the caches.
  74. Extending views
  75. ---------------
  76. There may be other situations in which you don't want to override the whole view, you just want to prepend or append some more content to it. In Elgg this is called *extending* a view.
  77. For example, instead of overriding the ``hello/world`` view, we could extend it like so:
  78. .. code-block:: php
  79. elgg_extend_view('hello/world', 'hello/greeting');
  80. If the contents of ``/views/default/hello/greeting.php`` is:
  81. .. code-block:: php
  82. <h2>How are you today?</h2>
  83. Then every time we call ``elgg_view('hello/world');``, we'll get:
  84. .. code-block:: html
  85. <h1>Hello, World!</h1>
  86. <h2>How are you today?</h2>
  87. You can prepend views by passing a value to the 3rd parameter that is less than 500:
  88. .. code-block:: php
  89. // appends 'hello/greeting' to every occurrence of 'hello/world'
  90. elgg_extend_view('hello/world', 'hello/greeting');
  91. // prepends 'hello/greeting' to every occurrence of 'hello/world'
  92. elgg_extend_view('hello/world', 'hello/greeting', 450);
  93. Note that if you extend the core css view like this:
  94. .. code-block:: php
  95. elgg_extend_view('css', 'custom/css');
  96. You **must** do so within code that is executed by engine/start.php (normally this would mean your plugin's init code). Because the core css view is loaded separately via a ``<link>`` tag, any extensions you add will not have the same context as the rest of your page.
  97. .. _guides/views#altering-view-input:
  98. Altering view input
  99. -------------------
  100. It may be useful to alter a view's ``$vars`` array before it's rendered.
  101. Since 1.11, before each view rendering the ``$vars`` array is filtered by the :ref:`plugin hook <guides/hooks-list#views>` ``[view_vars, view_name]``. Each registered handler function is passed these arguments:
  102. * ``$hook`` - the string ``"view_vars"``
  103. * ``$type`` - the view name being rendered (the first argument passed to ``elgg_view()``)
  104. * ``$returnvalue`` - the ``$vars`` array
  105. * ``$params`` - an array containing: the unaltered ``$vars`` under the key ``vars``; :ref:`viewtype <guides/views#viewtypes>` being rendered under the key ``viewtype``; the view name under the key ``view``.
  106. Altering view input example
  107. ---------------------------
  108. Here we'll alter the default pagination limit for the comments view:
  109. .. code-block:: php
  110. // inside myplugin_init()
  111. elgg_register_plugin_hook_handler('view_vars', 'page/elements/comments', 'myplugin_alter_comments_limit');
  112. function myplugin_alter_comments_limit($hook, $type, $vars, $params) {
  113. // only 10 comments per page
  114. $vars['limit'] = elgg_extract('limit', $vars, 10);
  115. return $vars;
  116. }
  117. .. _guides/views#altering-view-output:
  118. Altering view output
  119. --------------------
  120. Sometimes it is preferable to alter the output of a view instead of overriding it.
  121. The output of each view is run through the :ref:`plugin hook <guides/hooks-list#views>` ``[view, view_name]`` before being returned by ``elgg_view()``. Each registered handler function is passed these arguments:
  122. * ``$hook`` - the string ``"view"``
  123. * ``$type`` - the view name being rendered (the first argument passed to ``elgg_view()``)
  124. * ``$returnvalue`` - the rendered output of the view (or the return value of the last handler)
  125. * ``$params`` - an array containing the key ``viewtype`` with value being the :ref:`viewtype <guides/views#viewtypes>` being rendered
  126. To alter the view output, the handler just needs to alter ``$returnvalue`` and return a new string.
  127. Altering view output example
  128. ----------------------------
  129. Here we'll eliminate breadcrumbs that don't have at least one link.
  130. .. code-block:: php
  131. // inside myplugin_init()
  132. elgg_register_plugin_hook_handler('view', 'navigation/breadcrumbs', 'myplugin_alter_breadcrumb');
  133. function myplugin_alter_breadcrumb($hook, $type, $returnvalue, $params) {
  134. // we only want to alter when viewtype is "default"
  135. if ($params['viewtype'] !== 'default') {
  136. return $returnvalue;
  137. }
  138. // output nothing if the content doesn't have a single link
  139. if (false === strpos($returnvalue, '<a ')) {
  140. return '';
  141. }
  142. }
  143. Displaying entities
  144. ===================
  145. If you don't know what an entity is, :doc:`check this page out first </design/database>`.
  146. The following code will automatically display the entity in ``$entity``:
  147. .. code-block:: php
  148. echo elgg_view_entity($entity);
  149. As you'll know from the data model introduction, all entities have a *type* (object, site, user or group), and optionally a subtype (which could be anything - 'blog', 'forumpost', 'banana'). ``elgg_view_entity`` will automatically look for a view called ``type/subtype``; if there's no subtype, it will look for ``type/type``. Failing that, before it gives up completely it tries ``type/default``. (RSS feeds in Elgg generally work by outputting the ``object/default`` view in the 'rss' viewtype.)
  150. So for example, the view to display a blogpost might be ``object/blog``. The view to display a user is ``user/user``.
  151. Full and partial entity views
  152. =============================
  153. ``elgg_view_entity`` actually has a number of parameters, although only the very first one is required. The first three are:
  154. * ``$entity`` - The entity to display
  155. * ``$viewtype`` - The viewtype to display in (defaults to the one we're currently in, but it can be forced - eg to display a snippet of RSS within an HTML page)
  156. * ``$full_view`` - Whether to display a *full* version of the entity. (Defaults to false.)
  157. This last parameter is passed to the view as ``$vars['full_view']``. It's up to you what you do with it; the usual behaviour is to only display comments and similar information if this is set to true.
  158. .. _guides/views#listing-entities:
  159. Listing entities
  160. ================
  161. This is then used in the provided listing functions. To automatically display a list of blog posts (:doc:`see the full tutorial </tutorials/blog>`), you can call:
  162. .. code-block:: php
  163. echo elgg_list_entities(array(
  164. 'type' => 'object',
  165. 'subtype' => 'blog',
  166. ));
  167. This function checks to see if there are any entities; if there are, it first displays the ``navigation/pagination`` view in order to display a way to move from page to page. It then repeatedly calls ``elgg_view_entity`` on each entity, before returning the result.
  168. Note that ``elgg_list_entities`` allows the URL to set its ``limit`` and ``offset`` options, so set those explicitly if you need particular values (e.g. if you're not using it for pagination).
  169. Because it does this, Elgg knows that it can automatically supply an RSS feed - it extends the ``metatags`` view (which is called by the header) in order to provide RSS autodiscovery, which is why you can see the orange RSS icon on those pages.
  170. If your entity list will display the entity owners, you can improve performance a bit by preloading all owner entities:
  171. .. code-block:: php
  172. echo elgg_list_entities(array(
  173. 'type' => 'object',
  174. 'subtype' => 'blog',
  175. // enable owner preloading
  176. 'preload_owners' => true,
  177. ));
  178. See also :doc:`check this page out first </design/database>`.
  179. Since 1.11, you can define an alternative view to render list items using ```'item_view'``` parameter.
  180. In some cases, default entity views may be unsuitable for your needs. Using ```item_view``` allows you to customize the look, while preserving pagination, list's HTML markup etc.
  181. Consider these two examples:
  182. .. code-block:: php
  183. echo elgg_list_entities_from_relationship(array(
  184. 'type' => 'group',
  185. 'relationship' => 'member',
  186. 'relationship_guid' => elgg_get_logged_in_user_guid(),
  187. 'inverse_relationship' => false,
  188. 'full_view' => false,
  189. ));
  190. .. code-block:: php
  191. echo elgg_list_entities_from_relationship(array(
  192. 'type' => 'group',
  193. 'relationship' => 'invited',
  194. 'relationship_guid' => (int) $user_guid,
  195. 'inverse_relationship' => true,
  196. 'item_view' => 'group/format/invitationrequest',
  197. ));
  198. In the first example, we are displaying a list of groups a user is a member of using the default group view. In the second example, we want to display a list of groups the user was invited to. Since invitations are not entities, they do not have their own views and can not be listed using ``elgg_list_*``. We are providing an alternative item view, that will use the group entity to display an invitation that contains a group name and buttons to access or reject the invitation.
  199. Using a different templating system
  200. ===================================
  201. .. warning::
  202. This functionality is deprecated as of Elgg 1.12. It will be removed in 2.0.
  203. It affects the behavior of templates globally, which is almost sure to cause
  204. breakages and therefore we suspect no one uses it in practice.
  205. You can write your own templating system if you want to.
  206. Before going through the motions of drawing views, Elgg checks the ``$CONFIG->template_handler`` variable to see if it contains the name of a callable function. If it does, the function will be passed the view name and template vars, and the return value of this function will be returned instead of the standard output:
  207. .. code-block:: php
  208. return $template_handler($view, $vars);
  209. Related
  210. =======
  211. .. toctree::
  212. :maxdepth: 1
  213. views/page-structure
  214. views/simplecache
  215. views/foot-vs-footer