Views in Elgg 2.0

Views and the Simplecache systems have been overhauled in Elgg 2.0 for gains in performance, flexibility, and ease of development.

All pages are views. Unlike 1.x which required hijacking requests via hooks or taking over page handling completely, in 2.0 you can override most pages by simple view overrides: Just copy the view (e.g. resources/river or resource/index) into your plugin views.

All core images are views. Nearly all images like default profile and file thumbnails are now views, and easily changeable without writing hook handlers. How can we do this?...

Static view files. Common file types (not only JS and CSS but also images, HTML, swfs, etc.) can now serve as views, either by placing them in the views folder or by linking to them using a new config file (views.php) within your plugin. This makes them trivial to override via plugins and they're automatically available with versioned URLs by the Simplecache system.

You can see exactly which file is serving each view via the Developer Tools view inspector.

Simplecache is fast. With a simple symlink, views (and assets) can be served directly by the web server, bypassing the overhead of PHP and MySQL, and allowing full HTTP support.

cd /path/to/elggroot
ln -s /path/to/elggdata/views_simplecache cache

For sites not using a caching proxy (e.g. Varnish), this should free up resources and serve those files much more quickly.

Even when Simplecache is off during development, it now can send lightweight 304 responses for a bit better client-side performance.

No more css/ and js/ in views. JS and CSS views are no longer segregated into separate directory structures and now can live alongside the other views used in your components. Via an aliasing subsystem, views in 1.x plugins will mostly work without modification, even if they extend legacy view names like "css/elgg" (upgrade guide).

Under the hood. For the curious, these changes were made possible by having the views system directly map files to views. Previously each view was mapped to a directory tree and core views weren't mapped at all, leading to run-time guesswork about which file to choose and a few functions with unexpected return values, like elgg_get_view_location().

Cruft removal. We also removed a few obscure and virtually unused view features and back compatibility APIs for very old plugins.

Plugin developers should carefully read the upgrade guide, but if your views usage was up-to-date with 1.9 standards (e.g. you don't use the "display" hook or have views that expect $vars['url']), we don't expect problems.

Steve Clay

Core Elgg team member, developer for University of Florida College of Education

Latest comments