Download the PHP package darkstar/view without Composer
On this page you can find all versions of the php package darkstar/view. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download darkstar/view
More information about darkstar/view
Files in darkstar/view
Package view
Short Description Provides an implementation of the TemplateView and TwoStepView patterns, with support for helpers and for closures as templates, using PHP itself as the templating language.
License BSD-2-Clause
Homepage https://github.com/elevenone/View
Informations about the package view
This is a fork from Aura View Changed for php 7.x
Aura View
This package provides an implementation of the TemplateView and TwoStepView patterns using PHP itself as the templating language. It supports both file-based and closure-based templates along with helpers and sections.
It is preceded by systems such as
Savant
,
Zend_View
, and
Solar_View
.
Foreword
Installation
This library requires PHP 5.4 or later; we recommend using the latest available version of PHP as a matter of principle. It has no userland dependencies.
It is installable and autoloadable via Composer as aura/view.
Alternatively, download a release or clone this repository, then require or include its autoload.php file.
Quality
To run the unit tests at the command line, issue composer install
and then ./vendor/bin/phpunit
at the package root. This requires Composer to be available as composer
.
This library attempts to comply with PSR-1, PSR-2, and PSR-4. If you notice compliance oversights, please send a patch via pull request.
Community
To ask questions, provide feedback, or otherwise communicate with the Aura community, please join our Google Group, follow @auraphp on Twitter, or chat with us on #auraphp on Freenode.
Getting Started
Instantiation
To instantiate a View object, use the ViewFactory:
Escaping Output
Security-minded observers will note that all the examples in this document use manually-escaped output. Because this package is not specific to any particular media type, it does not come with escaping functionality.
When you generate output via templates, you must escape it appropriately for security purposes. This means that HTML templates should use HTML escaping, CSS templates should use CSS escaping, XML templates should use XML escaping, PDF templates should use PDF escaping, RTF templates should use RTF escaping, and so on.
For a good set of HTML escapers, please consider Aura.Html.
Registering View Templates
Now that we have a View, we need to add named templates to its view template registry. These are typically PHP file paths, but templates can also be closures. For example:
The browse.php
file may look something like this:
Note that we use echo
, and not return
, in templates.
N.b.: The template logic will be executed inside the View object scope, which means that
$this
in the template code will refer to the View object. The same is true for closure-based templates.
Setting Data
We will almost always want to use dynamic data in our templates. To assign a data collection to the View, use the setData()
method and either an array or an object. We can then use data elements as if they are properties on the
View object.
N.b.: Recall that
$this
in the template logic refers to the View object, so that data assigned to the View can be accessed as properties on$this
.
The setData()
method will overwrite all existing data in the View object. The addData()
method, on the other hand, will merge with existing data in the View object.
Invoking A One-Step View
Now that we have registered a template and assigned some data to the View, we tell the View which template to use, and then invoke the View:
The $output
in this case will be something like this:
Using Sub-Templates (aka "Partials")
Sometimes we will want to split a template up into multiple pieces. We can
render these "partial" template pieces using the render()
method in our main template code.
First, we place the sub-template in the view registry (or in the layout registry if it for use in layouts). Then we render()
it from inside the main template code. Sub-templates can use any naming scheme we like. Some systems use the convention of prefixing partial templates with an underscore, and the following example will use that convention.
Second, we can pass an array of variables to be extracted into the local scope of the partial template. (The $this
variable will always be available regardless.)
For example, let's split up our browse.php
template file so that it uses a sub-template for displaying items.
We extract the item-display code from browse.php
into _item.php
:
Then we modify browse.php
to use the sub-template:
The output will be the same as earlier when we invoke the view.
N.b.: Alternatively, we can use
include
orrequire
to execute a PHP file directly in the current template scope.
Using Sections
Sections are similar to sub-templates (aka "partials") except that they are captured inline for later use. In general, they are used by view templates to capture output for layout templates.
For example, we can capture output in the view template to a named section ...
... and then use that output in a layout template:
In addition, the setSection()
method can be used to set the section body directly, instead of capturing it:
Using Helpers
The ViewFactory instantiates the View with an empty HelperRegistry to manage helpers. We can register closures or other invokable objects as helpers through the HelperRegistry. We can then call these helpers as if they are methods on the View.
This library does not come with any view helpers. You will need to add your own helpers to the registry as closures or invokable objects.
Custom Helper Managers
The View is not type-hinted to any particular class for its helper manager. This means you may inject an arbitrary object of your own at View construction time to manage helpers. To do so, pass a helper manager of your own to the ViewFactory.
For a comprehensive set of HTML helpers, including form and input helpers, please consider the Aura.Html package and its HelperLocator as an alternative to the HelperRegistry in this package. You can pass it to the ViewFactory like so:
Rendering a Two-Step View
To wrap the main content in a layout as part of a two-step view, we register
layout templates with the View and then call setLayout()
to pick one of
them for the second step. (If no layout is set, the second step will not be
executed.)
Let's say we have already set the browse
template above into our view registry. We then set a layout template called default
into the layout registry:
The default.php
layout template might look like this:
We can then set the view and layout templates on the View object and then invoke it:
The output from the inner view template is automatically retained and becomes available via the getContent()
method on the View object. The layout template then calls getContent()
to place the inner view results in the outer layout template.
N.b. We can also call
setLayout()
from inside the view template, allowing us to pick a layout as part of the view logic.
The view template and the layout template both execute inside the same View object. This means:
-
All data values are shared between the view and the layout. Any data assigned to the view, or modified by the view, is used as-is by the layout.
-
All helpers are shared between the view and the layout. This sharing situation allows the view to modify data and helpers before the layout is executed.
- All section bodies are shared between the view and the layout. A section that is captured from the view template can therefore be used by the layout template.
Closures As Templates
The view and layout registries accept closures as templates. For example, these are closure-based equivlents of the browse.php
and _item.php
template files above:
When registering a closure-based template, continue to use echo
instead of return
when generating output. The closure is rebound to the View object, so $this
in the closure will refer to the View just as it does in a file-based template.
A bit of extra effort is required with closure-based sub-templates (aka "partials"). Whereas file-based templates automatically extract the passed array of variables into the local scope, a closure-based template must:
-
Define a function parameter to receive the injected variables (the
$vars
param in the_item
template); and, - Extract the injected variables using
extract()
. Alternatively, the closure may use the injected variables parameter directly.
Aside from that, closure-based templates work exactly like file-based templates.
Registering Template Search Paths
We can also tell the view and layout registries to search the filesystem for templates. First, we tell the registry what directories contain template files:
When we refer to named templates later, the registry will search from the first directory to the last. For finer control over the search paths, we can call prependPath()
to add a directory to search earlier, or appendPath()
to add a directory to search later. Regardless, the View will auto-append .php
to the end of template names when searching through the directories.
Changing The Template File Extension
By default, each TemplateRegistry will auto-append .php
to template file names. If the template files end with a different extension, change it usin the setTemplateFileExtension()
method:
The TemplateRegistry instance used for the layouts is separate from the one for the views, so it may be necessary to change the template file extension on it as well:
Advanced Configuration
Alternatively you can pass $helpers, mapping information or paths for views and layouts as below.
If you are passing the mapping information or paths to views
and layouts
you don't need to
call the getViewRegistry
or getLayoutRegistry
and set
the mapping information.
Eg :