Laravel Framework

Development Topics:

– Gulp
– IoC container
– Service containers
– Route clousers.
– Construction injection
– Method injection
– Form model binding
– Route model binding
– Accessor

Laravel’s main features

Modularity, Testability, Routing, Configuration management, Query builder and ORM, Schema builder, migrations, and seeding
Template engine, E-mailing, Authentication, Redis, Queues, Event and command bus

others
More expressive, More consistent, More testablem, More feature complete:

 

Installing the illuminate/html package

Add the following lines in the require section of composer.json file and runt the composer update command.
“illuminate/html”: “~5.0”

After the completion of the installation process, register the service provider in config/app.php by adding the following value into the providers array:
‘Illuminate\Html\HtmlServiceProvider’

Now register facades by adding these two key value pairs in the aliases array:
‘Form’=> ‘Illuminate\Html\FormFacade’,
‘HTML’=> ‘Illuminate\Html\HtmlFacade’

The service container and request lifecycle

The public/ directory is meant to act as the document root; in other words, the
directory in which your web server starts looking after every incoming request.
Once URL rewriting is properly set up, every request that does not match an existing
file or directory hits the /public/index.php file. This file includes the Composer
autoloader file, which loads in dependencies (including the Laravel framework
components) and also where to look for your application’s code. Your application is
then bootstrapped, loading configuration variables based on the environment. Once
this is done, it instantiates a new service container instance, which in turn handles
the incoming request, uses the HTTP method and URL used to access the application
(such as POST /comments), and passes the request off to the correct controller action
or route for handling.
==============================

adding auth functionality on laravel application:
php artisan make:auth

Eloquent ORM

Introduction
Basic Usage
Mass Assignment
Insert, Update, Delete
Soft Deleting
Timestamps
Query Scopes
Global Scopes
Relationships
Querying Relations
Eager Loading
Inserting Related Models
Touching Parent Timestamps
Working With Pivot Tables
Collections
Accessors & Mutators
Date Mutators
Attribute Casting
Model Events
Model Observers
Model URL Generation
Converting To Arrays / JSON

Architecture Foundations

Service Providers
Service providers are the central place of all Laravel application bootstrapping. Your own application, as well as all of Laravel’s core services are bootstrapped via service providers.

But, what do we mean by “bootstrapped”? In general, we mean registering things, including registering service container bindings, event listeners, filters, and even routes. Service providers are the central place to configure your application.

If you open the config/app.php file included with Laravel, you will see a providers array. These are all of the service provider classes that will be loaded for your application. Of course, many of them are “deferred” providers, meaning they will not be loaded on every request, but only when the services they provide are actually needed.

Service Container
The Laravel service container is a powerful tool for managing class dependencies. Dependency injection is a fancy word that essentially means this: class dependencies are “injected” into the class via the constructor or, in some cases, “setter” methods.

Almost all of your service container bindings will be registered within service providers, so all of these examples will demonstrate using the container in that context. However, if you need an instance of the container elsewhere in your application, such as a factory, you may type-hint the Illuminate\Contracts\Container\Container contract and an instance of the container will be injected for you. Alternatively, you may use the App facade to access the container.

Within a service provider, you always have access to the container via the $this->app instance variable.

Contracts

Laravel’s Contracts are a set of interfaces that define the core services provided by the framework. For example, a Queue contract defines the methods needed for queueing jobs, while the Mailer contract defines the methods needed for sending e-mail.You may have several questions regarding contracts. Why use interfaces at all? Isn’t using interfaces more complicated?Let’s distill the reasons for using interfaces to the following headings: loose coupling and simplicity.

Facades
Facades provide a “static” interface to classes that are available in the application’s service container. Laravel ships with many facades, and you have probably been using them without even knowing it! Laravel “facades” serve as “static proxies” to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.

In the context of a Laravel application, a facade is a class that provides access to an object from the container. The machinery that makes this work is in the Facade class. Laravel’s facades, and any custom facades you create, will extend the base Facade class.

Request Lifecycle
When using any tool in the “real world”, you feel more confident if you understand how that tool works. Application development is no different. When you understand how your development tools function, you feel more comfortable and confident using them.

The entry point for all requests to a Laravel application is the public/index.php file. All requests are directed to this file by your web server (Apache / Nginx) configuration. The index.php file doesn’t contain much code. Rather, it is simply a starting point for loading the rest of the framework.

Next, the incoming request is sent to either the HTTP kernel or the console kernel, depending on the type of request that is entering the application. These two kernels serve as the central location that all requests flow through. For now, let’s just focus on the HTTP kernel, which is located in app/Http/Kernel.php.

The HTTP kernel extends the Illuminate\Foundation\Http\Kernel class, which defines an array of bootstrappers that will be run before the request is executed. These bootstrappers configure error handling, configure logging, detect the application environment, and perform other tasks that need to be done before the request is actually handled.

The HTTP kernel also defines a list of HTTP middleware that all requests must pass through before being handled by the application. These middleware handle reading and writing the HTTP session, determine if the application is in maintenance mode, verifying the CSRF token, and more.

The method signature for the HTTP kernel’s handle method is quite simple: receive a Request and return a Response. Think of the Kernel as being a big black box that represents your entire application. Feed it HTTP requests and it will return HTTP responses.

One of the most important Kernel bootstrapping actions is loading the service providers for your application. All of the service providers for the application are configured in the config/app.php configuration file’s providers array. First, the register method will be called on all providers, then, once all providers have been registered, the boot method will be called.

Once the application has been bootstrapped and all service providers have been registered, the Request will be handed off to the router for dispatching. The router will dispatch the request to a route or controller, as well as run any route specific middleware.

Application Structure
The default Laravel application structure is intended to provide a great starting point for both large and small applications. Of course, you are free to organize your application however you like. Laravel imposes almost no restrictions on where any given class is located – as long as Composer can autoload the class.

The app directory ships with a variety of additional directories such as Console, Http, and Providers. Think of the Console and Http directories as providing an API into the “core” of your application. The HTTP protocol and CLI are both mechanisms to interact with your application, but do not actually contain application logic. In other words, they are simply two ways of issuing commands to your application. The Console directory contains all of your Artisan commands, while the Http directory contains your controllers, filters, and requests.

The Commands directory, of course, houses the commands for your application. Commands represent jobs that can be queued by your application, as well as tasks that you can run synchronously within the current request lifecycle.

The Events directory, as you might expect, houses event classes. Of course, using classes to represent events is not required; however, if you choose to use them, this directory is the default location they will be created by the Artisan command line.

The Handlers directory contains the handler classes for both commands and events. Handlers receive a command or event and perform logic in response to that command or event being fired.

The Services directory contains various “helper” services your application needs to function. For example, the Registrar service included with Laravel is responsible for validating and creating new users of your application. Other examples might be services to interact with external APIs, metrics systems, or even services that aggregate data from your own application.

The Exceptions directory contains your application’s exception handler and is also a good place to stick any exceptions thrown by your application.

reset root password with wrong mysql config

I’d suggest to forget the bat file and do it manually:

Go to your xampp\mysql\bin\ folder
Edit my.ini and insert skip-grant-tables below [mysqld]
Restart MySQL
Set new password for your root user by running UPDATE mysql.user SET Password=PASSWORD(‘new_password’) WHERE User=’root’ in phpMyAdmin in the mysql database (or just leave it like this if MySQL cannot be accessed from remote hosts)

ref: http://stackoverflow.com/questions/4124447/reset-root-password-with-wrong-mysql-config

Execute a HTTP POST Using PHP CURL

//extract data from the post
extract($_POST);

//set POST variables
$url = 'http://domain.com/get-post.php';
$fields = array(
	'lname' => urlencode($last_name),
	'fname' => urlencode($first_name),
	'title' => urlencode($title),
	'company' => urlencode($institution),
	'age' => urlencode($age),
	'email' => urlencode($email),
	'phone' => urlencode($phone)
);

//url-ify the data for the POST
foreach($fields as $key=>$value) { $fields_string .= $key.'='.$value.'&'; }
rtrim($fields_string, '&');

//open connection
$ch = curl_init();

//set the url, number of POST vars, POST data
curl_setopt($ch,CURLOPT_URL, $url);
curl_setopt($ch,CURLOPT_POST, count($fields));
curl_setopt($ch,CURLOPT_POSTFIELDS, $fields_string);

//execute post
$result = curl_exec($ch);

//close connection
curl_close($ch);