Le fonctionnement des vues dans Elgg est similaire au fonctionnement des feuilles de style : c'est un emboîtement de petits fichiers (les "vues") les uns dans les autres, qui vont du plus général au plus spécifique et particulier.

Ainsi, toute page affichée à aprtir d'Elgg suit un schéma d'organisation qui ressemble en gros à :

pageshells --> canvas --> layouts --> "grands blocs" / conteneurs -> blocs de contenus --> wrappers --> bloc d'un contenu --> éléments du contenu --> éléments "atomiques"

Définition, principes d'organisation et utilisation des vues

à compléter et traduire depuis http://docs.elgg.org/wiki/Views

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.

The Views system handles both the layout of pages and generation of chunks of presentation output (like a footer or a toolbar).

View Types

It's possible that you might want your Elgg site to have several sets of interface pages. For example:

• Standard HTML
• HTML optimised for accessibility
• Mobile Internet
• iPhone
• Embeddable widget

In Elgg, one set of interface pages is called a view type. Each individual display element - a blog post, a user icon, a title - is called a view.

Elgg has a powerful views system, which ensures that presentation is separate from logic and allows for advanced features like automatic RSS generation, a swift-to-develop mobile interface, and the alternative interfaces suggested above.

Using views

Views have string names - for example, the name for the site CSS view is just 'css'. They can also be broken up into groups, for example 'page_elements/title', 'page_elements/header' and so on.

Each view is stored in a separate file. The directory structure reflects the view type that the view is in. The default view type is called 'default', so the 'page_elements/header' view described above is stored in:

• /views
  • /default
    • /page_elements
      • /header.php

To display this view, you would call:

echo elgg_view('page_elements/header', array('variable1' => $value1, 'variable2' => $value2));

The variables array is how you pass values to the view. These are made available within the view as elements of the $vars array. In the example above, variable1 would be made available within header.php as $vars['variable1'], variable2 would be made available as $vars['variable2'], and so on.

$vars is also prepopulated with a couple of important variables:

• $vars['url'] is always the URL of the current Elgg site
• $vars['user'] is the current user object, if any is logged in
• $vars['config'] is the configuration object (normally stored in the global variable $CONFIG)

Views in plugins

Each plugin may have its own /views directory. This is treated by Elgg to be the same as the root views directory, with the exception that views belonging to a plugin will take precedence over the ones provided by the Elgg core.

Therefore, /mod/myplugin/views/default/page_elements/header.php will completely overwrite the page header, as it's considered to have a view name of page_elements/header and will supercede the version in core.

You can manually do the same thing with the set_view_location function:

set_view_location($view_name, $full_path_to_view_file);

Important note: From Elgg 1.5 the views system caches view locations. This means if you are a plugin developer who has added a new view to their plugin during development you must either enable/disable the plugin or run upgrade.php for the new view to be discovered.

Extending views

A plugin may extend a view by calling the following function:

elgg_extend_view('view/to/extend', 'view/to/extend/with');

An optional third parameter sets the priority. The original view is given a priority of 500, so setting the priority to below that means the new view content occurs before the original view; setting a priority over 500 (the default behaviour) causes the content to occur after the original view.

If you extend the core css view like this:

elgg_extend_view('css', 'my/custom/css');

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 "" tag, any extensions you add will not have the same context as the rest of your page. It may be easier to extend some other view with a "