Download the PHP package werx/core without Composer

werx.Core

Core libraries for the Werx Project

• Routing - Aura.Router
• HTTP Abstraction - Symfony\HttpFoundation
• Templates - Plates Native PHP Templates
• Database Abstraction - Illuminate\Database
• Configuration Management - werx\Config
• Unit Tests - PHPUnit (of course, why use anything else?)

Learn more at The Werx Project or see werx\Skeleton for a reference implementation.

Installation

Installation of this package is easy with Composer. If you aren't familiar with the Composer Dependency Manager for PHP, you should read this first.

Suggested Directory Structure

• Your application resides in src/ and has a base namespace of Example\Project
• Your controllers are in src/controllers/ and have a namespace of Example\Project\Controllers
  • Your controllers extend werx\Core\Controller

Front Controller

Your web/index.php serves as the front controller and contains the following content:

This will turn control of dispatching the request to the werx.Core dispatcher.

Routing

Routing is handled by the Aura Router.

Some sensible default routes are provided out of the box in the dispatcher.

The following will all call the index() method of your Home controller.

• http://example.com/path/to/index.php
• http://example.com/path/to/index.php/home
• http://example.com/path/to/index.php/home/index

This one will also call index, but will also pass the value "1" to the index method.

• http://example.com/path/to/index.php/home/index/1

Likewise, you can call the bar() method of the Foo controller like this:

• http://example.com/path/to/index.php/foo/bar

If you want to supply different routes, just create a config directory under source with a file named routes.php that defines the routes you need.

For more information on routing options, see https://github.com/auraphp/Aura.Router.

Configuration

The configuration manger is built on werx\Config

Basic Configuration Usage

Multiple Environment Configuration Support

The configuration manager supports different configs for different environments (local, dev, test, prod, etc). To activate per-environment configs, create a sub-directory of src/config named the same as your environment. This directory should contain configuration files with any items from the main config you want to override in that environment.

Example:

src/config/test/database.php

You can tell the app which environment you are running in by modifying the content of src/config/environment to contain the name of your active environment.

Then load your config as you normally would. The configuration items will be merged between the default config environment-specific overrides.

See the werx\Config Docs for more information on configuration management.

Extra Configuration Helper Methods

getBaseUrl()

Returns the absolute url to the base of your application without the filename (ex. index.php). Accepts an optional path to append to the base url as an argument.

getSiteUrl()

Returns the absolute url to the base of your application, including the filename (ex. index.php). Accepts an optional path to append to the site url as an argument.

Templates

Templates are powered by the Plates Project, which is part of The League of Extraordinary Packages.

Within this project, all themes and layouts live in src/views.

Basic Template Usage

I've extended the standard Template class from Plates in 2 important ways:

• 1) I've added the output() method so you can display the rendered view without an echo if you like.
• 2) All variables are escaped before rendering/displaying the content to prevent cross site scripting.

If there are variables you don't want auto-escaped (example: pre-rendered HTML), you can prevent escaping by calling unguard('param_name').

Prefill

I've added some functionality to the Template class for easily getting default values in views when the variable doesn't exist.

Then in our view:

See the Plates Project documentation for more information on template usage.

HTTP Abstraction

HTTP Abstraction is provided by Symfony\HttpFoundation. This provides useful things like:

• Object-Oriented access to $_GET, $_POST, $_SESSION, $_COOKIE, etc.
• Internal/External Redirects
• JSON/JSONP Responses

$_GET and $_POST

The Core Controller has a reference to the httpFoundation Request object, but I find the syntax for accessing $_GET and $_POST attributes less than ideal. So, I've built a wrapper around the httpFoundation Request object to make the syntax friendlier.

Examples:

null is returned when trying to access a non-existent attribute from get/post. Pass a 2nd parameter to $this->input->get() or $this->input->post() to serve as the default value if you want something other than null.

In the default Request object, you have to pass true as the 3rd argument to $this->request->query->get() in order to access "deep" array keys. This is defaulted to true in my override.

See the Symfony Docs for more information on the HttpFoundation component.

Database

Database abstraction is handled by Illuminate\Database

Your model:

Instead of extending Eloquent\Model directly, you can extend werx\Core\Model (which extends Eloquent) to get easier access to the query builder.

See tests/resources/models/Captain for a working example.

Initialize the database before you try to use it.

Once your database has been initialized, you can call your ORM models from anywhere.

See the Laravel Eloquent Documentation for more info on the ORM.

You also have access to the fluent query builder.

See the Laravel Database Documentation for more info on the fluent query builder.

Multiple Database Connection Support

To initialize Eloquent with multiple database connections, you can pass an array of connection params to DB::init().

Then in your model, specify the connection to use.