alternative Language System

This pull request enhance the Core\Language to support an alternative improved Language System, built on top of PHP's native INTL extension, while the current API is completely preserved.

The new Language System use two framework-wide functions for strings translation, first one being __(), who is designed to be used into App, and the second being __d(), designed to be used on Language Domains;. those Language Domains being the Modules, the Templates or the System.

IMPORTANT: When a specified domain match both a Module and Template name, the Module will take precedence. In other words, there should no be a Module and a Template with the same name, for the Language System to work properly.

The usage of both translation functions is very simple, they containing the string to be translated and optionally, parameters. E.g.

// Get a translation for App Domain (default)
$translated = __('Hello, {0}', $username);

// Get a translation for Users Module Domain
$translated = __d('users', 'Welcome back, {0}!', $username);

// Get a translation for System Domain
$translated = __d('system', 'File not found: {0}', $filename);

To note that the Domains are specified in snake_case transformation, and that for translation string's parameters is used the ICU notation, like is used also by the PHP's INTL extension.

There is a utility script introduced, called scripts/makelangs.php, and it should be used to update the Framework's Language files, after introducing new translation strings in your application.

The Language files used by this new Language System are called messages.php and will be found into usual locations, i.e. app/Language/En/messages.php or app/Modules/Users/Language/En/messages.php

ORM Added

This pull-request introduce a simple ORM Model, without Relations support yet, in a Laravel-esque style.

Even someone can argue that an Object Relational Model without Relations is just a pompous name for a Database Entity, it is strong enough to permit a similar usage with a ORM one, if we do not ask about the Relations support. E.g.

use Helpers\Password;
use App\Models\ORM\User;

$user = User::find(1);

$user->password = Password::make($password);

$user->save();

use App\Models\ORM\User;

$user = User::find(5);

if ($user !== null) {
   // Delete this User Record from Database
   $user->delete();
}

use Helpers\Password;
use App\Models\ORM\User;

$user = User::create(array(
    'username' => 'mark',
    'password' => Password::make('markpass');
    'realname' => 'Mark Darwin',
    'email'    => '[email protected]'
));

// Do something with the User Model instance which is already saved into Database.

use App\Models\ORM\User;

$users = User::all();

// Do something with the array of User Models retrieved

use App\Models\ORM\User;

$users = User::where('role', '=', 'admin')->get();

// Do something with the array of User Models retrieved

To note that for those example was used the following Users Model:

namespace App\Models\ORM;

use Database\ORM\Model as BaseModel;

class User extends BaseModel
{
    protected $table = 'users';

    protected $primaryKey = 'id';
}

To note that an ORM Model name should be always at singular, for example User, not Users and the recommended namespace for them is App\Models\ORM, from housekeeping reasons.

Like the Database\Model, the Database\ORM\Model can transparently call the methods of a ORM-aware QueryBuilder, built on top of Database\Query\Builder.

Finally, to note that the API is similar with the ORM Models from Illuminate\Database 4.x, and if a Method exists in our implementation, it will behave similar with the Laravel one.

Queued Events

This pull-request introduce improvements into Events\Dispatcher as in support for Queued Events and a new method Events\Dispatcher@until.

The Queued Events is a method to add a number of Events to a Queue, then firing them together, flushing the Queue. E.g

// Queue the Events
Event::queue('test', array('This is the First Event'));
Event::queue('test', array('This is the Second Event'));
Event::queue('test', array('This is the Third Event'));

// Flush the Queue, firing all defined Events
Event::flush('test'); 

The new method Events\Dispatcher@until is about firing a Event until first Listener returns a valid and non-null response, which will be returned. Its usage is simple:

$response = Event::until('testing', $payload);

if($response !== null) {
    // Do something with $response
}

Implementing a simple Events management

This pull request introduce a simple Events\Dispatcher, in a Laravel-esque style, and its associated Facade.

The idea behind the Events is the ability to send data, as parameters, to interested Listeners and call them, when a Event happen. The Listeners could be a Closure or static Class Method.

To note that the Events\Dispatcher do not instantiate a Listener's Class, then the called method is a must to be static.

Its usage is simple; first we have to register a Listener, adding:

use Event;

// Add a Listener to the Event 'test'.
Event::listen('test', 'App\Events\Test@handle');

Where the class App\Events\Test is

namespace App\Events;

class Test
{
    public static function handle($message)
    {
        echo $message;
    }
}

Then, when is need, we could fire the Event:

// Prepare the Event payload.
$payload = array(
    'Hello, this is a Event!',
);

// Fire the Event 'test'.
Event::fire('test', $payload);

added FastCache support

This pull request introduce a very simple Cache Helper, built in top of phpFastCache, and called Helpers\FastCache. Its usage is very simple:

use Helpers\FastCache;

$cache = FastCache::getInstance();

// Use any phpFastCache methods on FastCache instance.

To note that the Helpers\FastCache practically acts like a Decorator for phpFastCache, then could be called any phpFastCache method, its API applying.

Also, note that this pull request introduce a new directory into App, called Cache, to store the Cache files.

collection of recent changes

Remove the View::renderModule() associated Exception throwing and assorted optimizations.

This pull request introduce a new Auth\Guard method, which check the User state as guest with a very simple usage:

if(Auth::guest()) {
    // Do something, the User is not logged in.
}

Also, there are introduced optimizations of Auth System and a fix into App\Controllers\Users@profile.

Auto-configure the Table into Database\Model only in the child Classes.
Improve Auth\Guard and introduce a strong random string generator called str_random().
Move the Mailer on using the Composer Package of PHPMailer.
Improve the Helpers\Session@message and make the messages Templated.
Improved Auth\Auth; make configurable the Table columns used by Auth\Guard.
Make the Database\Query agnostic about the current used Database\Model
Fix compileAggregate in Database\Query.

Simplify the structure of the Reference Implementation of Users Authentication on Application

Merge pull request #803 from LuckyCyborg/master

Simplify the structure of the Reference Implementation of Users Authentication on Application

Adjust the Auth configuration

Add the missing option for the Auth configuration.

Small fix into app/Config.example.php

Merge pull request #801 from LuckyCyborg/master

Small fix into app/Config.example.php

introduce a simple but efficient **Auth** system

This pull-request introduce a simple but efficient Auth system, in a Laravel-esque style.

All the classes of that Auth system live in the namespace *\Auth* and is implemented also a reference structure for User Authentication in the *\App* namespace.

To note that additional Route Filters are added, to support this reference implementation and the properly configuration of Helpers\Encrypter, as in valid ENCRYPT_KEY, is required.

Being an Users Management, of course, a Database is required and in scripts/nova_users.sql you can find the associated MySQL dump for the users Table.

Important: as Database API is used the new one, living in the namespace **\Database**, then if you choose to use this Auth System, you should use that new Database API in the whole application and to not touch the Helpers\Database instances.

The reference implementation contains a class called App\Controllers\Auth which control the Users login and logout, as a base for your Users management.

The main Auth System classes are:

Auth\Auth - aliased as \Auth, which contains a simple manager of the current Guard instance.
Auth\Guard - the Authentication Guard, which handle the User authentication.
Auth\Model - an Users base Model, built on top of Database\Model and configurable via a Config entry.

The offered services are:
User Login with remembering - the solution use a strong encrypted Cookie for remembering the authenticated user. I.e.

// Prepare the Authentication credentials.
$credentials = array(
    'username' => Request::post('username'),
    'password' => Request::post('password')
);

// Prepare the 'remember' parameter.
if (Request::post('remember') == 'on') {
    $remember = true;
} else {
    $remember = false;
}

if(Auth::attempt($credentials, $remember)) {
    // User is authenticated there.
}

User Logout - using a simple command:

Auth::logout();

Authentication check, via a boolean command:

if(Auth::check()) {
    // User is authenticated there.
}

Current User information - the Auth have the ability to retrieve the authenticated User information, in a stdClass instance, fetched via PDO::FETCH_OBJ. No ORM Entities or data arrays are supported. i.e.

if(Auth::check()) {
    // User is authenticated there, retrieve its Record.
    $user = Auth::user();

   // Do something cool there.
}

Finally, to note that this Auth System do NOT offer support for User Registration or Credentials Recovery, being all about a simple, yet secure and strong, User Authentication.