Download the PHP package monomelodies/improse without Composer

On this page you can find all versions of the php package monomelodies/improse. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Example code of monomelodies/improse

Informations about the package improse

Improse

PHP5 View and templating front for MVC projects

Surprisingly, most MVC frameworks out there get Controllers and Views utterly wrong. If you've ever worked with one, you'll recognize the following pattern:

This is wrong for a number of reasons, all stemming from formal MVC theory:

  1. The View (which in the above case is actually a template, which is something different) is responsible for its own data. Here it is not; the Controller is instantiating a model and passing it on to the template/view.
  2. The template is acting as the View, which is wrong (they're separate concepts).
  3. There is now tight coupling between SomeController::indexAction and SomeModel, which would only be relevant if the action changes something (normally, a POST handler).

Improse is a simple view layer correcting these errors.

Installation

Composer (recommended)

Manual

  1. Download or clone the repository;
  2. Add /path/to/improse/src in your PSR-4 autoloader for the namespace Improse.

Basic usage

The base view defines a render method which renders the requested file. So you can also pass the rendered view to some other handler (e.g. an emitter):

Views also have a __toString method which simply returns the result of render, so the following two are actually equivalent:

The main difference is that since __toString cannot throw exceptions in PHP, it catches them and uses filp\whoops to display them instead. render on the other hand would just throw it.

Defining view data

All public members of the view are considered "view data" by the render method:

In the real world, your views will need to collect data to render. Hence you'll mostly use the View class as a base to extend off of:

Making templates useful

The basic behaviour for Improse views is to include the template file. Thus, you can pass HTML (or other static formats) to it, or a PHP file:

Nesting views

Views can also contain other views:

The template can now simply echo $page somewhere.

Most templating engines (see below) also support this, but it could come in very handy when you're mixing multiple templating systems, e.g. Twig, Blade and Moustache in different sections of your application. Improse is "templating-system-neutral" in that respect.

Tying templates to views

In any but the most trivial application, views will contain logic so you'll find yourself extending the base view for custom per-page or per-section views:

Note that you can still override the template to use on a per-case basis since we're calling the parent __constructor with an argument:

Just-in-time logic

You can also choose to place all your logic in an overridden render method. Just forward to parent::render() and return its result when you're done:

This strategy allows you to define all views up front, but only make them do heavy lifting (e.g. retrieving data from a RMDBS) when they actually get rendered (based on your application's logic).

Templating engines

Even though PHP is itself a templating engine, many people (including us...) prefer to use a separate templating engine, e.g. Twig or Smarty.

Integrating a templating engine is a matter of overriding the render method in an extending class, and let it use its own logic. An example using Twig could look like this:

The default render implementation does nothing else, so your override only needs to handle the actual outputting (though of course you could let it do more, like logging or such).

Handling errors

Improse uses filp\whoops to pretty-print errors caused by exceptions in its __toString calls (since they cannot throw exceptions in PHP).

Since a "whoops" may be triggered in any sub-view, if you're really bothered about your error HTML being valid (since it might contain duplicate <head> tags for instance if they were already outputted), you should handle this in your application logic (e.g. using output buffering). Improse views offer a static whoops method which returns true if any error occured:

Of course, since you'll want to fix the error anyway you might as well dump it to screen anyway. But you could also be a bit more friendly depending on whether your app is in development or in production mode. Views also have a static $swallowErrors property. It defaults to false, but set it to any non-false value and a view with an error will render that instead (so ideally you'd put it to a string message like "Error! We're flogging the programmer!").

This is all so basic...

So you've read the above and looked at the Improse source code (which admittedly is extremely small). Maybe you find yourself wondering why you'd use Improse at all; it's only a few lines of code, after all.

But, it saves you some boilerplate code, and by extending the base view the template, variable en rendering logic are already in place. It also forces you to implement views in the correct MVC way :)

All versions of improse with dependencies

PHP Build Version
Package Version
Requires filp/whoops Version ^1.1
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package monomelodies/improse contains the following files

Loading the files please wait ....