Skip to content

Y
yii2
Commit a8a012b9 by Funson Lee
Options

Merge branch 'master' of github.com:yii2-chinesization/yii2

parents 1be66364 7ee00cd5
Showing with 1659 additions and 103 deletions
README.md
......@@ -11,18 +11,13 @@ Yii 2 requires PHP 5.4 and embraces the best practices and protocols found in mo
[![Latest Stable Version](https://poser.pugx.org/yiisoft/yii2/v/stable.png)](https://packagist.org/packages/yiisoft/yii2)
[![Total Downloads](https://poser.pugx.org/yiisoft/yii2/downloads.png)](https://packagist.org/packages/yiisoft/yii2)
[![Reference Status](https://www.versioneye.com/php/yiisoft:yii2/reference_badge.svg)](https://www.versioneye.com/php/yiisoft:yii2/references)
[![Build Status](https://secure.travis-ci.org/yiisoft/yii2.png)](http://travis-ci.org/yiisoft/yii2)
[![Dependency Status](https://www.versioneye.com/php/yiisoft:yii2/dev-master/badge.png)](https://www.versioneye.com/php/yiisoft:yii2/dev-master)
[![HHVM Status](http://hhvm.h4cc.de/badge/yiisoft/yii2-dev.png)](http://hhvm.h4cc.de/package/yiisoft/yii2-dev)
[![Code Coverage](https://scrutinizer-ci.com/g/yiisoft/yii2/badges/coverage.png?s=31d80f1036099e9d6a3e4d7738f6b000b3c3d10e)](https://scrutinizer-ci.com/g/yiisoft/yii2/)
[![Scrutinizer Quality Score](https://scrutinizer-ci.com/g/yiisoft/yii2/badges/quality-score.png?s=b1074a1ff6d0b214d54fa5ab7abbb90fc092471d)](https://scrutinizer-ci.com/g/yiisoft/yii2/)
[![Code Climate](https://codeclimate.com/github/yiisoft/yii2.png)](https://codeclimate.com/github/yiisoft/yii2)
[![Issue Stats Issues](http://issuestats.com/github/yiisoft/yii2/badge/issue)](http://issuestats.com/github/yiisoft/yii2)
[![Issue Stats Pull request](http://issuestats.com/github/yiisoft/yii2/badge/pr)](http://issuestats.com/github/yiisoft/yii2)
DIRECTORY STRUCTURE
-------------------
......
apps/advanced/tests/codeception/bin/yii
......@@ -22,6 +22,7 @@ $config = yii\helpers\ArrayHelper::merge(
'class' => 'yii\faker\FixtureController',
'fixtureDataPath' => '@tests/codeception/common/fixtures/data',
'templatePath' => '@tests/codeception/common/templates/fixtures',
'namespace' => 'tests\codeception\common\fixtures',
],
],
]
......
apps/basic/tests/codeception/bin/yii
......@@ -18,7 +18,8 @@ $config = yii\helpers\ArrayHelper::merge(
'fixture' => [
'class' => 'yii\faker\FixtureController',
'fixtureDataPath' => '@tests/codeception/fixtures',
'templatePath' => '@tests/codeception/templates'
'templatePath' => '@tests/codeception/templates',
'namespace' => 'tests\codeception\fixtures',
],
],
]
......
composer.json
......@@ -82,15 +82,15 @@
"bower-asset/jquery.inputmask": "3.1.*",
"bower-asset/punycode": "1.3.*",
"bower-asset/yii2-pjax": "2.0.*",
"bower-asset/bootstrap": "3.2.* | 3.1.*",
"bower-asset/bootstrap": "3.3.* | 3.2.* | 3.1.*",
"bower-asset/jquery-ui": "1.11.*@stable",
"bower-asset/typeahead.js": "0.10.*"
},
"require-dev": {
"phpunit/phpunit": "3.7.*",
"twig/twig": "*",
"smarty/smarty": "*",
"imagine/imagine": "v0.5.0",
"smarty/smarty": "~3.1",
"imagine/imagine": "0.5.*",
"swiftmailer/swiftmailer": "*",
"fzaninotto/faker": "*",
"cebe/indent": "*"
......
docs/guide-es/README.md
......@@ -49,11 +49,10 @@ Gestión de las peticiones
* [Información general](runtime-overview.md)
* [Bootstrapping](runtime-bootstrapping.md)
* [Routing](runtime-routing.md)
* [Routing y Creación de las URL](runtime-routing.md)
* [Peticiones (Requests)](runtime-requests.md)
* [Respuestas (Responses)](runtime-responses.md)
* [Sesiones (Sessions) y Cookies](runtime-sessions-cookies.md)
* **TBD** [Procesamiento y generación de las URL](runtime-url-handling.md)
* **TBD** [Gestión de errores](runtime-handling-errors.md)
* **TBD** [Registro de anotaciones](runtime-logging.md)
......@@ -126,7 +125,7 @@ Caché
* [Caché HTTP](caching-http.md)
Servicios Web RESTful
Servicios Web RESTful
---------------------
* **TBD** [Guía breve](rest-quick-start.md)
......
docs/guide-es/rest-authentication.md 0 → 100644
Autenticación
==============
A diferencia de las aplicaciones Web, las API RESTful son usualmente sin estado (stateless), lo que permite que las sesiones o las cookies no sean usadas. Por lo tanto, cada petición debe llevar alguna suerte de credenciales de autenticación, porque la autenticación del usuario no puede ser mantenida por las sesiones o las cookies. Una práctica común es enviar una pieza (token) secreta de acceso con cada petición para autenticar al usuario. Dado que una pieza de autenticación puede ser usada para identificar y autenticar solamente a un usuario, **el API de peticiones tiene que ser siempre enviado vía HTTPS para prevenir ataques que intervengan en la transmisión "man-in-the-middle" (MitM) **.
> Tip: Sin estado (stateless) se refiere a un protocolo en el que cada petición es una transacción independiente del resto de peticiones y la comunicación consiste en pares de peticion y respuesta, por lo que no es necesario retener información en la sesión.
Hay muchas maneras de enviar una pieza (token) de acceso:
* [Autorización Básica HTTP (HTTP Basic Auth)](http://en.wikipedia.org/wiki/Basic_access_authentication): la pieza de acceso es enviada como nombre de usuario. Esto sólo debe de ser usado cuando la pieza de acceso puede ser guardada de forma segura en la parte del API del consumidor. Por ejemplo, el API del consumidor es un programa ejecutándose en un servidor.
* Parámetro de la consulta: la pieza de acceso es enviada como un parámetro de la consulta en la URL de la API, p.e.,
`https://example.com/users?access-token=xxxxxxxx`. Debido que muchos servidores dejan los parámetros de consulta en los logs del servidor esta aproximación suele ser usada principalmente para servir peticiones `JSONP` que no usen las cabeceras HTTP para enviar piezas de acceso.
* [OAuth 2](http://oauth.net/2/): la pieza de acceso es obtenida por el consumidor por medio de una autorización del servidor y enviada al API del servidor según el protocolo OAuth 2 [Piezas HTTP de la portadora (HTTP Bearer Tokens)](http://tools.ietf.org/html/rfc6750).
Yii soporta todos los métodos anteriores de autenticación. Puedes crear nuevos métodos de autenticación de una forma fácil.
Para activar la autenticación para tus APIs, sigue los pasos siguientes:
1. Configura la propiedad [[yii\web\User::enableSession|enableSession]] de el componente `user` de la aplicación a false.
2. Especifica cuál método de autenticación planeas usar configurando la funcionalidad `authenticator` en las clases de la controladora REST.
3. Implementa [[yii\web\IdentityInterface::findIdentityByAccessToken()]] en tu [[yii\web\User::identityClass|clase de identidad de usuario]].
El paso 1 no es necesario pero sí recomendable para las APIs RESTful, pues son sin estado (stateless). Cuando [[yii\web\User::enableSession|enableSession]]
es false, el estado de autenticación del usuario puede NO ser mantenido (persisted) durante varias peticiones usando sesiones. Si embargo, la autenticación puede ser realizada para cada petición, la cual es realizada por los pasos 2 y 3.
> Tip: Puede configurar [[yii\web\User::enableSession|enableSession]] del componente de la aplicación `user` en la configuración de las aplicaciones si estás desarrollando APIs RESTful en términos de un aplicación. Si desarrollas un módulo de las APIs RESTful, puedes poner la siguiente línea en el método del módulo `init()`, tal y como sigue:
> ```php
public function init()
{
parent::init();
\Yii::$app->user->enableSession = false;
}
```
Por ejemplo, para usar HTTP Basic Auth, puedes configurar `authenticator` como sigue,
```php
use yii\filters\auth\HttpBasicAuth;
public function behaviors()
{
$behaviors = parent::behaviors();
$behaviors['authenticator'] = [
'class' => HttpBasicAuth::className(),
];
return $behaviors;
}
```
Si quires implementar las tres autenticaciones explicadas antes, puedes usar `CompositeAuth` de la siguiente manera,
```php
use yii\filters\auth\CompositeAuth;
use yii\filters\auth\HttpBasicAuth;
use yii\filters\auth\HttpBearerAuth;
use yii\filters\auth\QueryParamAuth;
public function behaviors()
{
$behaviors = parent::behaviors();
$behaviors['authenticator'] = [
'class' => CompositeAuth::className(),
'authMethods' => [
HttpBasicAuth::className(),
HttpBearerAuth::className(),
QueryParamAuth::className(),
],
];
return $behaviors;
}
```
Cada elemento en `authMethods` debe de ser el nombre de un método de autenticación de una clase o un array de configuración.
La implementación de `findIdentityByAccessToken()` es específico de la aplicación. Por ejemplo, en escenarios simples cuando cada usuario sólo puede terner una pieza (token) de acceso, puedes almacenar la pieza de acceso en la columna `access_token` en la tabla de usuario. El método debe de ser inmediatamente implementado en la clase `User` como sigue,
```php
use yii\db\ActiveRecord;
use yii\web\IdentityInterface;
class User extends ActiveRecord implements IdentityInterface
{
public static function findIdentityByAccessToken($token, $type = null)
{
return static::findOne(['access_token' => $token]);
}
}
```
Después que la autenticación es activada, tal y como se describe arriba, para cada petición de la API, la controladora solicitada puede intentar autenticar al usuario en su paso `beforeAction()`.
Si la autenticación ocurre, la controladora puede realizar otras comprobaciones (como son límite del ratio, autorización) y entonces ejecutar la acción. La identidad del usuario autenticado puede ser recogida via `Yii::$app->user->identity`.
Si la autenticación falla, una respuesta con estado HTTP 401 puede ser devuelta junto con otras cabeceras apropiadas (como son la cabecera para autenticación básica HTTP `WWW-Authenticate` ).
## Autorización <a name="authorization"></a>
Después de que un usuario se ha autenticado, probablementer querrás comprobar si él o ella tiene los permisos para realizar la acción pedida para el recurso pedido. Este proceso es llamado *autorización (authorization)* y está cubierto en detalle en la [Sección de Autorización](security-authorization.md).
Si tus controladoras extienden de [[yii\rest\ActiveController]], puedes sobreescribir (override) el método [[yii\rest\Controller::checkAccess()|checkAccess()]] para realizar la comprobación de la autorización. El método será llamado por las acciones contenidas en [[yii\rest\ActiveController]].
docs/guide-es/rest-error-handling.md 0 → 100644
Manejo de errores
==============
Cuando se maneja una petición del API RESTful, si ocurre un error en la petición del usuario o si algo inesperado ocurre en el servidor, simplemente puedes lanzar una excepción para notificar al usuario que algo erróneo ocurrió.
Si puedes identificar la causa del error (p.e., el recurso pedido no existe), debes considerar lanzar una excepción con el apropiado códig HTTP de estado (p.e., [[yii\web\NotFoundHttpException]] representa un código de estado 404). Yii enviará la respuesta a continuación con el correspondiente código de estado HTTP y el texto. Yii puede incluir también la representación serializada de la excepción en el cuerpo de la respuesta. Por ejemplo:
```
HTTP/1.1 404 Not Found
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{
"name": "Not Found Exception",
"message": "El recurso solicitado no ha sido encontrado.",
"code": 0,
"status": 404
}
```
La siguiente lista sumariza los códigos de estado HTTP que son usados por el framework REST:
* `200`: OK. Todo ha funcionado como se esperaba.
* `201`: El recurso ha creado con éxito en respuesta a la petición `POST`. La cabecera de situación `Location` contiene la URL apuntando al nuevo recurso creado.
* `204`: La petición ha sido manejada con éxito y el cuerpo de la respuesta no tiene contenido (como una petición `DELETE`).
* `304`: El recurso no ha sido modificado. Puede usar la versión en caché.
* `400`: Petición errónea. Esto puede estar causado por varias acciones de el usuario, como proveer un JSON no válido en el cuerpo de la petición, proveyendo parámetros de acción no válidos, etc.
* `401`: Autenticación fallida.
* `403`: El usuario autenticado no tiene permitido acceder a la API final.
* `404`: El recurso pedido no existe.
* `405`: Método no permitido. Por favor comprueba la cabecera `Allow` por los métodos HTTP permitidos.
* `415`: Tipo de medio no soportado. El tipo de contenido pedido o el número de versión no es válido.
* `422`: La validación de datos ha fallado (en respuesta a una petición `POST` , por ejemplo). Por favor, comprobad en el cuerpo de la respuesta el mensaje detallado.
* `429`: Demasiadas peticiones. La petición ha sido rechazada debido a un limitación de rango.
* `500`: Error interno del servidor. Esto puede estar causado por errores internos del programa.
## Personalizando la Respuesta al Error <a name="customizing-error-response"></a>
A veces puedes querer personalizar el formato de la respuesta del error por defecto . Por ejemplo, en lugar de depender del uso de diferentes estados HTTP para indicar los diferentes errores, puedes querer usar siempre el estado HTTP 200 y encajonar el código de estado HTTP en la respuesta, tal y como se ve en lo que sigue,
```
HTTP/1.1 200 OK
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{
"success": false,
"data": {
"name": "Not Found Exception",
"message": "The requested resource was not found.",
"code": 0,
"status": 404
}
}
```
Para lograr este objetivo, puedes responder al evento `beforeSend` de el componente `response` en la configuración de la aplicación:
```php
return [
// ...
'components' => [
'response' => [
'class' => 'yii\web\Response',
'on beforeSend' => function ($event) {
$response = $event->sender;
if ($response->data !== null && !empty(Yii::$app->request->get['suppress_response_code'])) {
$response->data = [
'success' => $response->isSuccessful,
'data' => $response->data,
];
$response->statusCode = 200;
}
},
],
],
];
```
El anterior código puede reformatear la respuesta (para ambas respuestas, exitosa o fallida) de forma aclaratoria cuando
`suppress_response_code` es pasado como un parámetro `GET`.
docs/guide-es/rest-rate-limiting.md 0 → 100644
Limitando el ratio (rate)
=============
Para prevenir el abuso, puedes considerar añadir un *límitación del ratio* (*rate limiting*) para tus APIs. Por ejemplo, puedes querer limitar el uso del API de cada usuario que no sea como mucho 100 llamadas al API dentro de un periodo de 10 minutos. Si demasiadas peticiones son recibidas de un usuario dentro del periodo de tiempo declarado , una respuesta con código de estado 429 (significa "Demasiadas peticiones") puede ser devuelto.
Para activar la limitación de ratio, la clase [[yii\web\User::identityClass|user identity class]] debe implementar [[yii\filters\RateLimitInterface]].
Este interface requiere la implementación de tres métodos:
* `getRateLimit()`: devuelve el número máximo de peticiones permitidas y el periodo de tiempo (p.e., `[100, 600]` significa que como mucho puede haber 100 llamadas al API dentro de 600 segundos).
* `loadAllowance()`: devuelve el número de peticiones que quedan permitidas y el tiempo (fecha/hora) UNIX con el último límite del ratio que ha sido comprobado.
* `saveAllowance()`: guarda ambos, el número que quedan de peticiones permitidas y el actual tiempo (fecha/hora) UNIX .
Tu puedes usar dos columnas en la tabla de usuario para guardar la información de lo permitido y la fecha/hora (timestamp). Con ambas definidas, entonces `loadAllowance()` y `saveAllowance()` pueden ser implementadas para leer y guardar los valores de las dos columnas correspondientes al actual usuario autenticado. Para mejorar el desempeño, también puedes considerar almacenar esas piezas de información en caché o almacenamiento NoSQL.
Una vez que la clase de identidad implementa el requerido interface, Yii puede usar automáticamente [[yii\filters\RateLimiter]] configurado como una acción de filtrado para [[yii\rest\Controller]] y mejorar la comprobación del limitador de ratio. El limitador de ratio puede lanzar una [[yii\web\TooManyRequestsHttpException]] cuando el límite del ratio es excedido.
Puedes configurar el limitador de ratio en tu clase REST de la controladora como sigue:
```php
public function behaviors()
{
$behaviors = parent::behaviors();
$behaviors['rateLimiter']['enableRateLimitHeaders'] = false;
return $behaviors;
}
```
Cuando la limitación de ratio está activada, por defecto cada respuesta puede ser enviada con las siguientes cabeceras de HTTP conteniendo la información actual del límite de ratio:
* `X-Rate-Limit-Limit`, el máximo número de peticiones permitidas en un periodo de tiempo
* `X-Rate-Limit-Remaining`, el número de peticiones restantes en el periodo de tiempo actual
* `X-Rate-Limit-Reset`, el número de segundos a esperar para pedir el máximo número de peticiones permitidas
Puedes desactivar estas cabeceras configurando [[yii\filters\RateLimiter::enableRateLimitHeaders]] a false, tal y como en el anterior ejemplo.
docs/guide-es/rest-resources.md 0 → 100644
Recursos
=========
Las APIs RESTful lo son todos para acceder y manipular *recursos (resources)*. Puedes observar los recursos en el paradigma MVC en [Modelos (models)](structure-models.md) .
Mientras que no hay restricción a cómo representar un recurso, en YII usualmente, puedes representar recursos como objetos de la clase [[yii\base\Model]] o sus clases hijas (p.e. [[yii\db\ActiveRecord]]), por las siguientes razones:
* [[yii\base\Model]] implementa el interface [[yii\base\Arrayable]] , el cual te permite personalizar como exponer los datos de los recursos a travès de las APIs RESTful.
* [[yii\base\Model]] soporta [Validación de entrada (input validation)](input-validation.md), lo cual es muy usado en las APIs RESTful para soportar la entrada de datos.
* [[yii\db\ActiveRecord]] provee un poderoso soporte para el acceso a datos en bases de datos y su manipulación, lo que lo le hace servir perfectamente si sus recursos de datos están en bases de datos.
En esta sección, vamos principalmente a describir como la clase con recursos que extiende de [[yii\base\Model]] (o sus clases hijas) puede especificar qué datos puede ser devueltos vía las APIs RESTful. Si la clase de los recursos no extiende de [[yii\base\Model]], entonces todas las variables públicas miembro serán devueltas.
## Campos (fields) <a name="fields"></a>
Cuando incluimos un recurso en una respuesta de la API RESTful, el recurso necesita ser serializado en una cadena.
Yii divide este proceso en dos pasos. Primero, el recurso es convertido en un array por [[yii\rest\Serializer]].
Segundo, el array es serializado en una cadena en el formato requerido (p.e. JSON, XML) por [[yii\web\ResponseFormatterInterface|response formatters]]. El primer paso es en el que debes de concentrarte principalmente cuando desarrolles una clase de un recurso.
Sobreescribiendo [[yii\base\Model::fields()|fields()]] y/o [[yii\base\Model::extraFields()|extraFields()]],
puedes especificar qué datos, llamados *fields*, en el recursos, pueden ser colocados en el array que le representa.
La diferencia entre estos dos métodos es que el primero especifica el conjunto de campos por defecto que deben ser incluidos en el array que los representa, mientras que el último especifica campos adicionales que deben de ser incluidos en el array si una petición del usuario final para ellos vía el parámetro de consulta `expand`. Por ejemplo,
```
// devuelve todos los campos declarados en fields()
http://localhost/users
// sólo devuelve los campos id y email, provistos por su declaración en fields()
http://localhost/users?fields=id,email
// devuelve todos los campos en fields() y el campo profile siempre y cuando esté declarado en extraFields()
http://localhost/users?expand=profile
// sólo devuelve los campos id, email y profile, siempre y cuando ellos estén declarados en fields() y extraFields()
http://localhost/users?fields=id,email&expand=profile
```
### Sobreescribiendo `fields()` <a name="overriding-fields"></a>
Por defecto, [[yii\base\Model::fields()]] devuelve todos los atributos de los modelos como si fueran campos, mientras [[yii\db\ActiveRecord::fields()]] sólo devuelve los atributos que tengan datos en la base de datos.
Puedes sobreescribir `fields()` para añadir, quitar, renombrar o redefinir campos. El valor de retorno de `fields()` ha de estar en un array. Las claves del array son los nombres de los campos y los valores del array son las correspondientes definiciones de los campos que pueden ser tanto nombres de propiedades/atributos o funciones anónimas que devuelven los correspondientes valores del los campos. En el caso especial de que el nombre de un campo sea el mismo que su definición puedes omitir la clave en el array. Por ejemplo,
```php
// explícitamente lista cada campo, siendo mejor usarlo cuando quieras asegurarte que los cambios
// en una tabla de la base de datos o en un atributo del modelo no provoque el cambio de tu campo (para mantener la compatibilidad anterior).
public function fields()
{
return [
// el nombre de campo es el mismo nombre del atributo
'id',
// el nombre del campo es "email", su atributo se denomina "email_address"
'email' => 'email_address',
// el nombre del campo es "name", su valor es definido está definido por una función anónima de retrollamada (callback)
'name' => function () {
return $this->first_name . ' ' . $this->last_name;
},
];
}
// el ignorar algunos campos, es mejor usarlo cuando heredas de una implementación padre
// y pones en la lista negra (blacklist) algunos campos sensibles
public function fields()
{
$fields = parent::fields();
// quita los campos con información sensible
unset($fields['auth_key'], $fields['password_hash'], $fields['password_reset_token']);
return $fields;
}
```
> Atención: Dado que, por defecto, todos los atributos de un modelo pueden ser incluidos en la devolución del API, debes
> examinar tus datos para estar seguro de que no contiene información sensible. Si se da este tipo de información,
> debes sobreescribir `fields()` para filtrarlos. En el ejemplo anterior, escogemos
> quitar `auth_key`, `password_hash` y `password_reset_token`.
### Sobreescribiendo `extraFields()` <a name="overriding-extra-fields"></a>
Por defecto, [[yii\base\Model::extraFields()]] no devuelve nada, mientras que [[yii\db\ActiveRecord::extraFields()]] devuelve los nombres de las relaciones que tienen datos (populated) obtenidos de la base de datos.
El formato de devolución de los datos de `extraFields()` es el mismo que el de `fields()`. Usualmente, `extraFields()` es principalmente usado para especificar campos cuyos valores sean objetos. Por ejemplo, dado la siguiente declaración de campo,
```php
public function fields()
{
return ['id', 'email'];
}
public function extraFields()
{
return ['profile'];
}
```
la petición `http://localhost/users?fields=id,email&expand=profile` puede devolver los siguientes datos en formato JSON :
```php
[
{
"id": 100,
"email": "100@example.com",
"profile": {
"id": 100,
"age": 30,
}
},
...
]
```
## Enlaces (Links) <a name="links"></a>
[HATEOAS](http://en.wikipedia.org/wiki/HATEOAS), es una abreviación de Hipermedia es el Motor del Estado de la Aplicación (Hypermedia as the Engine of Application State), promueve que las APIs RESTfull devuelvan información que permita a los clientes descubrir las acciones que soportan los recursos devueltos. El sentido de HATEOAS es devolver un conjunto de hiperenlaces con relación a la información, cuando los datos de los recursos son servidos por las APIs.
Las clases con recursos pueden soportar HATEOAS implementando el interfaz [[yii\web\Linkable]] . El interfaz contiene sólo un método [[yii\web\Linkable::getLinks()|getLinks()]] el cual debe de de devolver una lista de [[yii\web\Link|links]].
Típicamente, debes devolver al menos un enlace `self` representando la URL al mismo recurso objeto. Por ejemplo,
```php
use yii\db\ActiveRecord;
use yii\web\Link;
use yii\web\Linkable;
use yii\helpers\Url;
class User extends ActiveRecord implements Linkable
{
public function getLinks()
{
return [
Link::REL_SELF => Url::to(['user/view', 'id' => $this->id], true),
];
}
}
```
Cuando un objeto `User` es devuelto en una respuesta, puede contener un elemento `_links` representando los enlaces relacionados con el usuario, por ejemplo,
```
{
"id": 100,
"email": "user@example.com",
// ...
"_links" => [
"self": "https://example.com/users/100"
]
}
```
## Colecciones <a name="collections"></a>
Los objetos de los recursos pueden ser agrupados en *collections*. Cada colección contiene una lista de recursos objeto del mismo tipo.
Las colecciones pueden ser representadas como arrays pero, es usualmente más deseable representarlas como [proveedores de datos (data providers)](output-data-providers.md). Esto es así porque los proveedores de datos soportan paginación y ordenación de los recursos, lo cual es comunmente necesario en las colecciones devueltas con las APIs RESTful. Por ejemplo, la siguiente acción devuelve un proveedor de datos sobre los recursos post:
```php
namespace app\controllers;
use yii\rest\Controller;
use yii\data\ActiveDataProvider;
use app\models\Post;
class PostController extends Controller
{
public function actionIndex()
{
return new ActiveDataProvider([
'query' => Post::find(),
]);
}
}
```
Cuando un proveedor de datos está enviando una respuesta con el API RESTful, [[yii\rest\Serializer]] llevará la actual página de los recursos y los serializa como un array de recursos objeto. Adicionalmente, [[yii\rest\Serializer]]
puede incluir también la información de paginación a través de las cabeceras HTTP siguientes:
* `X-Pagination-Total-Count`: Número total de recursos;
* `X-Pagination-Page-Count`: Número de páginas;
* `X-Pagination-Current-Page`: Página actual (iniciando en 1);
* `X-Pagination-Per-Page`: Número de recursos por página;
* `Link`: Un conjunto de enlaces de navegación permitiendo al cliente recorrer los recursos página a página.
Un ejemplo se puede ver en la sección [Inicio rápido (Quick Start)](rest-quick-start.md#trying-it-out).
docs/guide-es/rest-response-formatting.md 0 → 100644
Dando Formato a la Respuesta
===================
Cuando se maneja una petición al API RESTful, una aplicación realiza usualmente los siguientes pasos que están relacionados con el formato de la respuesta:
1. Determinar varios factores que pueden afectar al formato de la respuesta, como son el tipo de medio, lenguaje, versión, etc.
Este proceso es también conocido como [Negociación de contenido (content negotiation)](http://en.wikipedia.org/wiki/Content_negotiation).
2. La conversión de objetos recursos en arrays, está descrito en la sección [Recursos (Resources)](rest-resources.md).
Esto es realizado por el serializador [[yii\rest\Serializer]].
> Tip: Serializar es convertir un elemento a un formato que nos permita guardardarlo de forma permanente, de modo que posteriormente, al recuperarlo, nos de una copia igual a la del elemento antes de ser inicialmente serializado.
3. La conversión de arrays en cadenas con el formato determinado por el paso de negociación de contenido. Esto es realizado por [[yii\web\ResponseFormatterInterface|response formatters]] registrado con el componente de la aplicación [[yii\web\Response::formatters|response]].
## Negociación de contenido (Content Negotiation) <a name="content-negotiation"></a>
Yii soporta la negoiciación de contenido a través del filtro [[yii\filters\ContentNegotiator]]. La clase controladora base del API RESTful [[yii\rest\Controller]] está equipada con este filtro bajo el nombre `contentNegotiator`.
El filtro provee tanto un formato de respuesta de negociación como una negociación de lenguaje. Por ejemplo, si la petición API RESTful contiene la siguiente cabecera,
```
Accept: application/json; q=1.0, */*; q=0.1
```
puede obtener una respuesta en formato JSON, como lo que sigue:
```
$ curl -i -H "Accept: application/json; q=1.0, */*; q=0.1" "http://localhost/users"
HTTP/1.1 200 OK
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
X-Powered-By: PHP/5.4.20
X-Pagination-Total-Count: 1000
X-Pagination-Page-Count: 50
X-Pagination-Current-Page: 1
X-Pagination-Per-Page: 20
Link: <http://localhost/users?page=1>; rel=self,
<http://localhost/users?page=2>; rel=next,
<http://localhost/users?page=50>; rel=last
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
[
{
"id": 1,
...
},
{
"id": 2,
...
},
...
]
```
En la parte de atrás, antes de que sea ejecutada una acción de la controladora del API RESTful, el filtro [[yii\filters\ContentNegotiator]] comprobará en la cabecera HTTP el `Accept` de la petición y pondrá como `'json'` [[yii\web\Response::format|response format]]. Después de que la acción sea ejecutada y devuelva el recurso objeto resultante o una colección resultante,
[[yii\rest\Serializer]] convertirá el resultado en un array. Y finalmente, [[yii\web\JsonResponseFormatter]] serializará el array en una cadena JSON incluyéndola en el cuerpo de la respuesta.
Por defecto, el API RESTful soporta tanto el formato JSON como el XML. Para soportar un nuevo formato, debes configurar la propiedad [[yii\filters\ContentNegotiator::formats|formats]] del filtro `contentNegotiator` tal y como sigue, en las clases de la controladora del API:
```php
use yii\web\Response;
public function behaviors()
{
$behaviors = parent::behaviors();
$behaviors['contentNegotiator']['formats']['text/html'] = Response::FORMAT_HTML;
return $behaviors;
}
```
Las claves de la propiedad `formats` son los tipos MIME soportados, mientras que los valores son los nombre de formato de respuesta correspondientes, los cuales han de estar soportados en [[yii\web\Response::formatters]].
## Serialización de Datos <a name="data-serializing"></a>
Como hemos descrito antes, [[yii\rest\Serializer]] es la pieza central para convertir recursos objeto o colecciones en arrays. Reconoce objetos tanto implementando [[yii\base\ArrayableInterface]] como [[yii\data\DataProviderInterface]]. El primer formateador es implementado principalmente para recursos objeto, mientras que el segundo para recursos collección.
Puedes configurar el serializador poniendo la propiedad [[yii\rest\Controller::serializer]] con un array de configuración.
Por ejemplo, a veces puedes querer simplificar la ayuda al trabajo de desarrollo del cliente incluyendo información de la paginación directamente en el cuerpo de la respuesta. Para hacer esto, configura la propiedad [[yii\rest\Serializer::collectionEnvelope]] como sigue:
```php
use yii\rest\ActiveController;
class UserController extends ActiveController
{
public $modelClass = 'app\models\User';
public $serializer = [
'class' => 'yii\rest\Serializer',
'collectionEnvelope' => 'items',
];
}
```
Puedes obtener la respuesta que sigue para la petición `http://localhost/users`:
```
HTTP/1.1 200 OK
Date: Sun, 02 Mar 2014 05:31:43 GMT
Server: Apache/2.2.26 (Unix) DAV/2 PHP/5.4.20 mod_ssl/2.2.26 OpenSSL/0.9.8y
X-Powered-By: PHP/5.4.20
X-Pagination-Total-Count: 1000
X-Pagination-Page-Count: 50
X-Pagination-Current-Page: 1
X-Pagination-Per-Page: 20
Link: <http://localhost/users?page=1>; rel=self,
<http://localhost/users?page=2>; rel=next,
<http://localhost/users?page=50>; rel=last
Transfer-Encoding: chunked
Content-Type: application/json; charset=UTF-8
{
"items": [
{
"id": 1,
...
},
{
"id": 2,
...
},
...
],
"_links": {
"self": "http://localhost/users?page=1",
"next": "http://localhost/users?page=2",
"last": "http://localhost/users?page=50"
},
"_meta": {
"totalCount": 1000,
"pageCount": 50,
"currentPage": 1,
"perPage": 20
}
}
```
docs/guide-es/rest-routing.md 0 → 100644
Enrutado
=======
Con los recursos y las clases controladoras preparadas, puedes acceder a los recursos usando una URL como `http://localhost/index.php?r=user/create`, parecida a la que usas con aplicaciones Web normales.
En la práctica, querrás usualmente usar URLs más bonitas y obtener ventajas de los comandos de acciones (verbos) HTTP.
Por ejemplo, una petición `POST /users` puede permitir el acceso a la acción `user/create`.
Esto puede realizarse fácilmente configurando el componente de la aplicación `urlManager` en la configuración tal y como sigue:
```php
'urlManager' => [
'enablePrettyUrl' => true,
'enableStrictParsing' => true,
'showScriptName' => false,
'rules' => [
['class' => 'yii\rest\UrlRule', 'controller' => 'user'],
],
]
```
En comparación con la gestión de URL en las aplicaciones Web, lo nuevo de lo anterior es el uso de [[yii\rest\UrlRule]] para el enrutado de las peticiones con el API RESTful. Esta clase especial que contiene la norma para gestionar las URLs puede crear todo un conjunto de URLs hijas para mantener el enrutado y la creación de URLs para la/s especificada/s controlador/as.
Por ejemplo, el código anterior es aproximadamente equivalente a las siguientes reglas:
```php
[
'PUT,PATCH users/<id>' => 'user/update',
'DELETE users/<id>' => 'user/delete',
'GET,HEAD users/<id>' => 'user/view',
'POST users' => 'user/create',
'GET,HEAD users' => 'user/index',
'users/<id>' => 'user/options',
'users' => 'user/options',
]
```
Y los siguientes puntos finales del API son mantenidos por la siguiente regla:
* `GET /users`: listado de todos los usuarios página a página;
* `HEAD /users`: enseña ĺa información resumén del usuario listado;
* `POST /users`: crea un nuevo usuario;
* `GET /users/123`: devuelve los detalles del usuario 123;
* `HEAD /users/123`: enseña la información resúmen del usuario 123;
* `PATCH /users/123` y `PUT /users/123`: actualizan al usuario 123;
* `DELETE /users/123`: borra el usuario 123;
* `OPTIONS /users`: presenta las acciones finales soportadas por `/users`;
* `OPTIONS /users/123`: presenta las acciones finales que soporta `/users/123`.
Puedes configurar las opciones `only` y `except` para explícitamente listar las acciones a soportar y cuales desabilitar, respectivamente. Por ejemplo,
```php
[
'class' => 'yii\rest\UrlRule',
'controller' => 'user',
'except' => ['delete', 'create', 'update'],
],
```
También puedes configurar `patterns` o `extraPatterns` para redifinir patrones existentes o añadir nuevos patrones que soportan esta regla.
Por ejemplo, para soportar la nueva acción `search` por `GET /users/search`, configura la opción `extraPatterns` como sigue,
```php
[
'class' => 'yii\rest\UrlRule',
'controller' => 'user',
'extraPatterns' => [
'GET search' => 'search',
],
```
Queda advertido que la ID de la controladora `user` aparece finalmente en plural tal que`users`.
Esto es debido a que [[yii\rest\UrlRule]] pluraliza de forma automáticalos IDs de las controladoras para ser usadas en los puntos finales.
Puedes desactivar este comportamiento poniendo a false [[yii\rest\UrlRule::pluralize]] , o si quieres usar algunos nombres especiales, debes configurar la propiedad [[yii\rest\UrlRule::controller]]. Dése cuenta que la pluralización de puntos finales del RESTful no siempre añade simplemente una "s" l final de la id de la controladora. Una controladora cuyo ID termina en "x", por ejemplo "BoxController" (con ID `box`), tiene el punto final del RESTful pluralizada a `boxes` por [[yii\rest\UrlRule]].
docs/guide-es/rest-versioning.md 0 → 100644
Versionado
==========
Una buena API ha de ser *versionada*: los cambios y las nuevas características son implementadas en las nuevas versiones del API, en vez de estar continuamente modificando sólo una versión. Al contrario que en las aplicaciones Web, en las cuales tienes total control del código de ambas partes lado del cliente y lado del servidor, las APIs están destinadas a ser usadas por los clientes fuera de tu control. Por esta razón, compatibilidades hacia atrás (BC Backward compatibility) de las APIs ha de ser mantenida siempre que sea posible. Si es necesario un cambio que puede romper la BC, debes de introducirla en la nueva versión del API, e incrementar el número de versión. Los clientes que la usan pueden continuar usando la antigua versión de trabajo del API; los nuevos y actualizados clientes pueden obtener la nueva funcionalidad de la nueva versión del API.
> Tip: referirse a [Semántica del versionado](http://semver.org/) para más información en el diseño del número de versión del API.
Una manera común de implementar el versionado de la API es embeber el número de versión en las URLs del AP.
Por ejemplo, `http://example.com/v1/users` se inicia por la versión 1 de la API del la parte final `/users`.
Otro método de versionado de la API , la cual está ganando predominancia recientemente, es poner el número de versión en las cabeceras de la petición HTTP. Esto se suele hacer típicamente a través la cabecera `Accept` :
```
// vía parámetros
Accept: application/json; version=v1
// vía de el tipo de contenido del vendedor
Accept: application/vnd.company.myapp-v1+json
```
Ambos métodos tienen sus pros y sus contras, y hay gran cantidad de debates sobre cada uno. Debajo puedes ver una estrategia práctica para el versionado de la API que es una mezcla de estos dos métodos:
* Pon cada versión superior del API en un módulo separado cuya ID es el número de la versión principal. (p.e. `v1`, `v2`).
Naturalmente, las URLs del API pueden contener números de versión superiores.
* Dentro de cada versión superior (y por tanto, dentro del correspondiente módulo), usa la cabecera de HTTP `Accept` para determinar el número de la menor versión y escribe código condicional para responder a la menor versión en consecuencia.
Para cada módulo sirviendo una versión superior, el módulo debe incluir los recursos y la clase controladora que especifican la versión. Para mejor separar la responsabilidad del código, puedes conservar un conjunto de recursos base y clases de controladores comunes, y hacer subclases de ellas en cada uno de los módulos de versión individual. Dentro de las subclases, impementa el código concreto como es `Model::fields()`.
Tu código puede estar organizado como lo que sigue:
```
api/
common/
controllers/
UserController.php
PostController.php
models/
User.php
Post.php
modules/
v1/
controllers/
UserController.php
PostController.php
models/
User.php
Post.php
v2/
controllers/
UserController.php
PostController.php
models/
User.php
Post.php
```
La configuración de su aplicación puede tener este aspecto:
```php
return [
'modules' => [
'v1' => [
'basePath' => '@app/modules/v1',
'controllerNamespace' => 'app\modules\v1\controllers',
],
'v2' => [
'basePath' => '@app/modules/v2',
'controllerNamespace' => 'app\modules\v2\controllers',
],
],
'components' => [
'urlManager' => [
'enablePrettyUrl' => true,
'enableStrictParsing' => true,
'showScriptName' => false,
'rules' => [
['class' => 'yii\rest\UrlRule', 'controller' => ['v1/user', 'v1/post']],
['class' => 'yii\rest\UrlRule', 'controller' => ['v2/user', 'v2/post']],
],
],
],
];
```
Como consecuencia de el anterior código, `http://example.com/v1/users` puede devolver la lista de usuarios de la versión 1, mientras
`http://example.com/v2/users` puede devolver la versión 2 de los usuarios.
Gracias a los módulos, el código de las diferentes principales versiónes puede ser aislado. Pero, los módulos, hacen posible reusar el código a través de los módulos vía clases base comunes y otros recursos compartidos.
Para traficar con los números de versión menores, puede obtener las ventajas de el contenido de las capacidades de las conductas de negociación provistas por el [[yii\filters\ContentNegotiator|contentNegotiator]]. La conducta `contentNegotiator` puede poner la propiead [[yii\web\Response::acceptParams]] cuando determina cuál tipo de contenido a soportar.
Por ejemplo, si una peticiónes enviada con la cabecera HTTP `Accept: application/json; version=v1`, entonces la conducta de negociación, [[yii\web\Response::acceptParams]] puede contener el valor `['version' => 'v1']`.
Basado en la información de versión contenida en `acceptParams`, puedes escribir código condicional en lugares como acciones, clases de recursos, serializadores, etc. para proveer la funcionalidad apropiada.
Desde la menor versión, por definición, es necesario mantener la compatibilidad hacia atrás, con suerte no tendrás demasiadas versiones a comporbar en tu código. De otra manera, probablemente puede ocurrir que necesites crear una versión principal.
docs/guide-es/runtime-overview.md
......@@ -17,6 +17,6 @@ Cada vez que una aplicación Yii gestiona una petición, se somete a un flujo de
El siguiente diagrama muestra como una aplicación gestiona una petición.
![Request Lifecycle](images/application-lifecycle.png)
![Request Lifecycle](images/request-lifecycle.png)
En esta sección, se describirá en detalle cómo funcionan algunos de estos pasos.
docs/guide-es/start-workflow.md
......@@ -79,7 +79,7 @@ Ciclo de Vida de una Petición (Request) <a name="request-lifecycle"></a>
El siguiente diagrama muestra cómo una aplicación maneja una petición.
![Ciclo de Vida de un Request](images/application-lifecycle.png)
![Ciclo de Vida de un Request](images/request-lifecycle.png)
1. Un usuario realiza una petición al [script de entrada](structure-entry-scripts.md) `web/index.php`.
2. El script de entrada carga la [configuración](concept-configurations.md) de la aplicación y crea
......
docs/guide-es/tutorial-yii-integration.md 0 → 100644
Trabajando con código de terceros
=================================
De tiempo en tiempo, puede necesitar usar algún código de terceros en sus aplicaciones Yii. O puedes querer usar Yii como una librería en otros sistemas de terceros. En esta sección, te enseñaremos cómo conseguir estos objetivos.
## Usando librerías de terceros en Yii <a name="using-libs-in-yii"></a>
Para usar una librería en una aplicación Yii, primeramente debes de asegurarte que las clases een la librería son incluidas adecuadamente o pueden ser cargadas de forma automática.
### Usando Paquetes de Composer <a name="using-composer-packages"></a>
Muchas librerías de terceros son liberadas en términos de paquetes [Composer](https://getcomposer.org/).
Puedes instalar este tipo de librerias siguiendo dos sencillos pasos:
1. modificar el fichero `composer.json` de tu aplicación y especificar que paquetes Composer quieres instalar.
2. ejecuta `composer install` para instalar los paquetes específicados.
Las clases en los paquetes Composer instalados pueden ser autocargados usando el cargador automatizado de Composer autoloader. Asegúrate que el fichero [script de entrada](structure-entry-scripts.md) de tu aplicación contiene las siguientes líneas para instalar el cargador automático de Composer:
```php
// instalar el cargador automático de Composer
require(__DIR__ . '/../vendor/autoload.php');
// incluir rl fichero de la clase Yii
require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
```
### Usando librerías Descargadas <a name="using-downloaded-libs"></a>
Si la librería no es liberada como un paquete de Composer, debes de seguir sus instrucciones de instalación para instalarla.
En muchos casos, puedes necesitar descargar manualmente el fichero de la versión y desempaquetarlo en el directorio `BasePath/vendor` , donde `BasePath` representa el [camino base (base path)](structure-applications.md#basePath) de tu aplicación.
Si la librería lleva su propio cargador automático (autoloader), puedes instalarlo en [script de entrada](structure-entry-scripts.md) de tu aplicación. Es recomendable que la instalación se termine antes de incluir el fichero `Yii.php` de forma que el cargador automático tenga precedencia al cargar de forma automática las clases.
Si la librería no provee un cargador automático de clases, pero la denominación de sus clases sigue el [PSR-4](http://www.php-fig.org/psr/psr-4/), puedes usar el cargador automático de Yii para cargar de forma automática las clases. Todo lo que necesitas es declarar un [alias raiz](concept-aliases.md#defining-aliases) para cada espacio de nombres (namespace) raiz usado en sus clases. Por ejemplo, asume que has instalado una librería en el directorio `vendor/foo/bar`, y que las clases de la librería están bajo el espacio de nombres raiz `xyz`. Puedes incluir el siguiente código en la configuración de tu aplicación:
```php
[
'aliases' => [
'@xyz' => '@vendor/foo/bar',
],
]
```
Si ninguno de lo anterior es el caso, estaría bien que la librería dependa del camino de inclusión (include path) de configuración de PHP para localizar correctamente e incluir los ficheros de las clases. Simplemente siguiendo estas instrucciones de cómo configurar el camino de inclusión de PHP.
En el caso más grave en el que la librería necesite incluir cada uno de sus ficheros de clases, puedes usar el siguiente método para incluir las clases según se pidan:
* Identificar que clases contiene la librería.
* Listar las clases y el camino a los ficheros correspondientes en `Yii::$classMap` en el script de entrada [script de entrada](structure-entry-scripts.md) de la aplicación. Por ejemplo,
```php
Yii::$classMap['Class1'] = 'path/to/Class1.php';
Yii::$classMap['Class2'] = 'path/to/Class2.php';
```
## Usando Yii en Sistemas de Terceros <a name="using-yii-in-others"></a>
Debido a que Yii provee muchas posibilidades excelentes, a veces puedes querer usar alguna de sus características para permitir el desarrollo o mejora de sistemas de terceros, como es WordPress, Joomla, o aplicaciones desarrolladas usando otros frameworks de PHP. Por ejemplo, puedes queres usar la clase [[yii\helpers\ArrayHelper]] o usar la característica [Active Record](db-active-record.md) en un sistema de terceros. Para lograr este objetivo, principalmente necesitas realizar dos pasos: instalar Yii , e iniciar Yii.
Si el sistema de terceros usa Composer para manejar sus dependencias, simplemente ejecuta estos comandos para instalar Yii:
```
composer require "yiisoft/yii2:*"
composer install
```
En otro caso, puedes [descargar](http://www.yiiframework.com/download/) el fichero de la edición de Yii y desempaquetarla en el directorio `BasePath/vendor`.
Después, debes de modificar el script de entrada de sistema de terceros para incluir el siguiente código al principio:
```php
require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
$yiiConfig = require(__DIR__ . '/../config/yii/web.php');
new yii\web\Application($yiiConfig); // No ejecutes run() aquí
```
Como puedes ver, el código anterior es muy similar al que puedes ver en [script de entrada](structure-entry-scripts.md) de una aplicación típica. La única diferencia es que después de que se crea la instancia de la aplicación, el método `run()` no es llamado. Esto es así porque llamando a `run()`, Yii se haría cargo del control del flujo de trabajo del manejo de las peticiones, lo cual no es necesario en este caso por estar ya es manejado por la aplicación existente.
Como en una aplicación Yii, debes configurar la instancia de la aplicación basándose en el entorno que se está ejecutando del sistema de terceros. Por ejemplo, para usar la característica [Active Record](db-active-record.md) , necesitas configurar `db` [componente de la aplicación](structure-application-components.md) con los parámetros de la conexión de base de datos usados por el sistema de terceros.
Ahora puedes usar muchas características provistas por Yii. Por ejemplo, puedes crear clases Active Record y usarlas para trabajar con bases de datos.
## Usando Yii 2 con Yii 1 <a name="using-both-yii2-yii1"></a>
Si estaba usando Yii 1 previamente, es como si tuvieras una aplicación Yii 1 funcionando. En vez de reescribir toda la aplicación en Yii 2, puedes solamente mejorarla usando alguna de las características sólo disponibles en Yii 2.
Esto se puede lograr tal y como se describe abajo.
> Nota: Yii 2 requiere PHP 5.4 o superior. Debes de estar seguro que tanto tu servidor como la aplicación existente lo soportan.
Primero, instala Yii 2 en tu aplicación siguiendo las instrucciones descritas en la [última subsección](#using-yii-in-others).
Segundo,modifica el script de entrada de la aplicación como sigue,
```php
// incluir la clase Yii personalizada descrita debajo
require(__DIR__ . '/../components/Yii.php');
// configuración para la aplicación Yii 2
$yii2Config = require(__DIR__ . '/../config/yii2/web.php');
new yii\web\Application($yii2Config); // No llamar a run()
// configuración para la aplicación Yii 1
$yii1Config = require(__DIR__ . '/../config/yii1/main.php');
Yii::createWebApplication($yii1Config)->run();
```
Debido a que ambos Yii 1 y Yii 2 tiene la clase `Yii` , debes crear una versión personalizada para combinarlas.
El código anterior incluye el fichero con la clase `Yii` personalizada, que tiene que ser creada como sigue.
```php
$yii2path = '/path/to/yii2';
require($yii2path . '/BaseYii.php'); // Yii 2.x
$yii1path = '/path/to/yii1';
require($yii1path . '/YiiBase.php'); // Yii 1.x
class Yii extends \yii\BaseYii
{
// copy-paste the code from YiiBase (1.x) here
}
Yii::$classMap = include($yii2path . '/classes.php');
// registrar el autoloader de Yii2 autoloader via Yii1
Yii::registerAutoloader(['Yii', 'autoload']);
// crear el contenedor de inyección de dependencia
Yii::$container = new yii\di\Container;
```
¡Esto es todo!. Ahora, en cualquier parte de tu código, puedes usar `Yii::$app` para acceder a la instancia de la aplicación de Yii 2, mientras `Yii::app()` proporciona la instancia de la aplicación de Yii 1 :
```php
echo get_class(Yii::app()); // genera 'CWebApplication'
echo get_class(Yii::$app); // genera 'yii\web\Application'
```
docs/guide-es/widget-bootstrap.md 0 → 100644
Widgets de Bootstrap
====================
> Nota: Esta sección está bajo desarrollo.
Yii incluye soporta las marcas y componentes del framework [Bootstrap 3](http://getbootstrap.com/) (también conocido como "Twitter Bootstrap"). Bootstrap es un excelente, adaptable framework que puede aumentar la velocidad de desarrollo de los procesos del lado del cliente.
El núcleo de Bootstrap está represntado en dos partes:
- Elementos básicos de CSS, como son un sistema de diseño en formato cuadrícula , tipografía, clases de ayuda (helpers), y utilidades adapatables(responsive).
- Componentes preparados para su uso, tales como formularios, menús, paginación, cajas modales, pestañas, etc
Elementos básicos
------
Yii no hace uso de elementos básicos de boostrap en el código PHP ya que HTML es muy simple por sí mismo, en este caso. Puedes encontrar detalle del uso de estos elementos básicos en [sitio web de la documentación de bootstrap](http://getbootstrap.com/css/). Aún así Yii provee una manera conveniente de incluir los elementos básicos de los recursos de bootstrap en tus páginas con una simple línea añadida a `AppAsset.php` localizada en tu directorio `@app/assets` :
```php
public $depends = [
'yii\web\YiiAsset',
'yii\bootstrap\BootstrapAsset', // Esta línea
];
```
Usar bootstrap a través de el gestor de recursos Yii te permite minimizar estos recursos y combinar con tus propios recursos cuando sea necesario..
Widgets de Yii
-----------
Componentes más complejos de bootstrap components están envueltos dentro de widgets de Yii para permitir una sintaxis más robusta e integrar con las posibilidades y características del framework. Todos los widgets pertenecen al espacio de nombres `\yii\bootstrap` :
- [[yii\bootstrap\ActiveForm|ActiveForm]]
- [[yii\bootstrap\Alert|Alert]]
- [[yii\bootstrap\Button|Button]]
- [[yii\bootstrap\ButtonDropdown|ButtonDropdown]]
- [[yii\bootstrap\ButtonGroup|ButtonGroup]]
- [[yii\bootstrap\Carousel|Carousel]]
- [[yii\bootstrap\Collapse|Collapse]]
- [[yii\bootstrap\Dropdown|Dropdown]]
- [[yii\bootstrap\Modal|Modal]]
- [[yii\bootstrap\Nav|Nav]]
- [[yii\bootstrap\NavBar|NavBar]]
- [[yii\bootstrap\Progress|Progress]]
- [[yii\bootstrap\Tabs|Tabs]]
Usando los ficheros .less de Bootstrap directamente
-------------------------------------------
Si quieres incluir el [Css Bootstrap directamente en tus ficheros less](http://getbootstrap.com/getting-started/#customizing) puedes necesitar desactivar la carga los ficheros css originales de bootstrap.
Esto lo puedes hacer poniendo la propiedad css de [[yii\bootstrap\BootstrapAsset|BootstrapAsset]] vacía.
Para esto necesitas configurar el `assetManager` [componente de la aplicación](structure-application-components.md) como sigue:
```php
'assetManager' => [
'bundles' => [
'yii\bootstrap\BootstrapAsset' => [
'css' => [],
]
]
]
```
docs/guide-es/widget-jui.md 0 → 100644
Widgets de Jquery UI
====================
> Nota: Esta sección está en desarrollo.
Además de lo anterior, Yii incluye soporte para la librería jquery [jQuery UI](http://api.jqueryui.com/). jQuery UI es un probado conjunto de interacciones con el interface de usuario, efectos, widgets, y temas sobre la librería JavaScript de jquery.
widgets de Yii
--------------
Los componentes más complejos de jQuery UI están envueltos dentro de los widgets de Yii para permitir una sintaxis más robusta e integralas con las características del framework. Todos los widgets pertenecen al espacio de nombre `\yii\jui` :
- [[yii\jui\Accordion|Accordion]]
- [[yii\jui\AutoComplete|AutoComplete]]
- [[yii\jui\DatePicker|DatePicker]]
- [[yii\jui\Dialog|Dialog]]
- [[yii\jui\Draggable|Draggable]]
- [[yii\jui\Droppable|Droppable]]
- [[yii\jui\Menu|Menu]]
- [[yii\jui\ProgressBar|ProgressBar]]
- [[yii\jui\Resizable|Resizable]]
- [[yii\jui\Selectable|Selectable]]
- [[yii\jui\Slider|Slider]]
- [[yii\jui\SliderInput|SliderInput]]
- [[yii\jui\Sortable|Sortable]]
- [[yii\jui\Spinner|Spinner]]
- [[yii\jui\Tabs|Tabs]]
\ No newline at end of file
docs/guide-fr/start-workflow.md
......@@ -74,7 +74,7 @@ Cycle de vie d'une requête <a name="request-lifecycle"></a>
Le diagramme suivant présente la manière dont une application traite une requête.
![Cycle de Vie d'une Requête](images/application-lifecycle.png)
![Cycle de Vie d'une Requête](images/request-lifecycle.png)
1. Un utilisateur fait une requête au [script de démarrage](structure-entry-scripts.md) `web/index.php`.
2. Le script de démarrage charge la [configuration](concept-configurations.md) de l'application et créé une instance d'[application](structure-applications.md) pour traiter la requête.
......
docs/guide-ja/README.md
......@@ -50,7 +50,7 @@ All Rights Reserved.
* [概要](runtime-overview.md)
* [ブートストラップ](runtime-bootstrapping.md)
* [ルーティング](runtime-routing.md)
* [ルーティングと URL 生成](runtime-routing.md)
* [リクエスト](runtime-requests.md)
* [レスポンス](runtime-responses.md)
* [セッションとクッキー](runtime-sessions-cookies.md)
......@@ -122,9 +122,9 @@ All Rights Reserved.
* [概要](caching-overview.md)
* [データキャッシュ](caching-data.md)
* [断片キャッシュ](caching-fragment.md)
* [フラグメントキャッシュ](caching-fragment.md)
* [ページキャッシュ](caching-page.md)
* [HTTP Caching](caching-http.md)
* [HTTP キャッシュ](caching-http.md)
RESTful ウェブサービス
......@@ -136,7 +136,7 @@ RESTful ウェブサービス
* [ルーティング](rest-routing.md)
* [レスポンスの書式設定](rest-response-formatting.md)
* [認証](rest-authentication.md)
* [速度制限](rest-rate-limiting.md)
* [転送レート制限](rest-rate-limiting.md)
* [バージョン管理](rest-versioning.md)
* [エラー処理](rest-error-handling.md)
......
docs/guide-ja/caching-fragment.md 0 → 100644
フラグメントキャッシュ
================
フラグメントキャッシュは、ウェブページの断片をキャッシュすることを言います。例えば、ページ内の表に年間販売の概要が表示されている場合、リクエスト毎にこの表を生成するのにかかる時間を削減するために、キャッシュにこの表を格納することができます。フラグメントキャッシュは [データキャッシュ](caching-data.md) 上に構築されています。
フラグメントキャッシュを使用するには [ビュー](structure-views.md) で以下の構文を使用します:
```php
if ($this->beginCache($id)) {
// ... ここに生成するコンテンツを書く ...
$this->endCache();
}
```
つまり [[yii\base\View::beginCache()|beginCache()]] と [[yii\base\View::endCache()|endCache()]] をペアにして囲み、その中にコンテンツ生成ロジックを書いていきます。コンテンツがキャッシュ内で見つかった場合、キャッシュされたコンテンツをレンダリングし [[yii\base\View::beginCache()|beginCache()]] は false を返します。結果として、コンテンツ生成ロジックはスキップされます。それ以外の場合はコンテンツ生成ロジックが呼ばれ、そして [[yii\base\View::endCache()|endCache()]] が呼ばれたとき生成されたコンテンツがキャプチャされ、キャッシュに格納されます。
[データキャッシュ](caching-data.md) と同様に、キャッシュされたコンテンツを識別するためにユニークな `$id` が必要になります。
## キャッシュのオプション <a name="caching-options"></a>
[[yii\base\View::beginCache()|beginCache()]] メソッドの 2 番目のパラメータを配列にすることで、フラグメントキャッシュに関する追加のオプションを指定することもできます。裏で、この配列のオプションは実際にフラグメントキャッシュ機能を実装している [[yii\widgets\FragmentCache]] ウィジェットを構成するために使用されます。
### 持続時間 <a name="duration"></a>
おそらくフラグメントキャッシュで通常よく使われるであろうオプションは [[yii\widgets\FragmentCache::duration|duration]] でしょう。このオプションにはコンテンツがどれだけの時間キャッシュ内において有効であるかを指定します。以下のコードは最大で 1 時間コンテンツの断片をキャッシュします:
```php
if ($this->beginCache($id, ['duration' => 3600])) {
// ... ここに生成するコンテンツを書く ...
$this->endCache();
}
```
オプションがセットされていない場合は、デフォルトである 60 が使われ、つまり有効期限が 60 秒間のキャッシュされたコンテンツを意味します。
### 依存関係 <a name="dependencies"></a>
[データキャッシュ](caching-data.md#cache-dependencies) と同様に、キャッシュされたコンテンツの断片は依存関係を持つことができます。例えば、表示されている投稿の内容は、投稿が変更されたか否かに依存する、といった具合です。
依存関係を指定するには [[yii\widgets\FragmentCache::dependency|dependency]] オプションに [[yii\caching\Dependency]] オブジェクトを指定するか、または依存関係オブジェクトを作成するための配列構成を指定します。以下のコードはコンテンツの断片が `updated_at` カラムの値の変化に依存していることを指定しています:
```php
$dependency = [
'class' => 'yii\caching\DbDependency',
'sql' => 'SELECT MAX(updated_at) FROM post',
];
if ($this->beginCache($id, ['dependency' => $dependency])) {
// ... ここに生成するコンテンツを書く ...
$this->endCache();
}
```
### バリエーション <a name="variations"></a>
キャッシュされたコンテンツはいくつかのパラメータによって変化させることもできます。例えば、複数の言語をサポートしているウェブアプリケーションに対して、ビューコードの同じ部分を、異なる言語で生成することができます。現在のアプリケーションの言語に応じて、キャッシュされたコンテンツに変更を加えるといったことが可能になります。
キャッシュのバリエーションを指定するには [[yii\widgets\FragmentCache::variations|variations]] オプションに配列で、それぞれが特定のバリエーションの要素を表すスカラー値をセットします。例えば、言語によってキャッシュされたコンテンツを変化させるには、以下のコードを使うことができます:
```php
if ($this->beginCache($id, ['variations' => [Yii::$app->language]])) {
// ... ここに生成するコンテンツを書く ...
$this->endCache();
}
```
### トグルキャッシュ <a name="toggling-caching"></a>
また、ある条件が満たされた場合にのみフラグメントキャッシュを有効にすることもできます。たとえば、フォームが表示されているページに対して、最初の (GET リクエストによる) リクエストの場合だけはキャッシュしたいと思いますが、その後の (POST リクエストによる) フォームの表示では、フォームにユーザ入力が含まれている可能性があるため、キャッシュをすべきではありません。これを行うには、以下のように [[yii\widgets\FragmentCache::enabled|enabled]] オプションをセットします:
```php
if ($this->beginCache($id, ['enabled' => Yii::$app->request->isGet])) {
// ... ここに生成するコンテンツを書く ...
$this->endCache();
}
```
## キャッシュのネスト <a name="nested-caching"></a>
フラグメントキャッシュはネストすることができます。つまり、キャッシュされる断片を、より大きなキャッシュされる断片で囲むことができます。例えば、コメントが内側のフラグメントキャッシュ内にキャッシュされ、それらが外側のフラグメントキャッシュに記事内容と一緒にキャッシュされます。以下のコードは 2 つのフラグメントキャッシュをどのようにネストできるかを示したものです:
```php
if ($this->beginCache($id1)) {
// ...コンテンツ生成ロジック...
if ($this->beginCache($id2, $options2)) {
// ...コンテンツ生成ロジック...
$this->endCache();
}
// ...コンテンツ生成ロジック...
$this->endCache();
}
```
ネストされたキャッシュには、異なるキャッシュオプションを設定することができます。 たとえば、上記の例における内側のキャッシュと外側のキャッシュに対して、異なる持続期間の値を設定する事が可能です。 これによって、外側のキャッシュでキャッシュされたデータが無効になった場合でも、内側のキャッシュが有効な内側の断片を提供することが可能になります。 しかし、その逆は真ではありません。 外側のキャッシュが有効であると判断された場合には、内側のキャッシュが無効になった後でも、外側のキャッシュが古くなったコンテンツのコピーを提供し続けます。 ネストされたキャッシュの持続時間や依存関係の設定を間違うと、無効になった内側のキャッシュデータが外側のキャッシュに残り続けることになるので、注意が必要です。
## ダイナミックコンテンツ <a name="dynamic-content"></a>
フラグメントキャッシュを使用する際、出力全体が比較的静的で、一ヶ所ないし数ヶ所だけが例外的に動的であるというような状況に遭遇します。例えば、ページ上部にはメインメニューバーと現在のユーザの名前とが一緒に表示される場合があります。他には、リクエスト毎に実行しなければいけない PHP のコードが含まれている場合(例えば、アセットバンドルを登録するためのコード)などです。この両方の問題は、いわゆる *ダイナミックコンテンツ* 機能によって解決することができます。
ダイナミックコンテンツは、それがフラグメントキャッシュの中に含まれていても、キャッシュすべきではない出力の部分を意味します。コンテンツを常に動的にするためには、外側のコンテンツがキャッシュから提供されている場合でも、すべてのリクエストに対して、いくつかのPHP コードを実行することにより生成しなければいけません。
以下のように、ダイナミックコンテンツを目的の場所に挿入するには、キャッシュされた断片内で [[yii\base\View::renderDynamic()]] を呼び出します。
```php
if ($this->beginCache($id1)) {
// ...コンテンツ生成ロジック...
echo $this->renderDynamic('return Yii::$app->user->identity->name;');
// ...コンテンツ生成ロジック...
$this->endCache();
}
```
[[yii\base\View::renderDynamic()|renderDynamic()]] メソッドはパラメータとして PHP コードの一部を使用します。PHP コードの戻り値は、ダイナミックコンテンツとして扱われます。同じ PHP コードはすべてのリクエストに対して実行されますが、囲まれている断片がキャッシュから提供されているか否かは問いません。
docs/guide-ja/caching-http.md 0 → 100644
HTTP キャッシュ
============
前の節で説明したサーバーサイドのキャッシュに加えて、ウェブアプリケーションは、同じページコンテンツを生成し送信する時間を節約するために、クライアントサイドでもキャッシュを利用することができます。
クライアントサイドのキャッシュを使用するには、レンダリング結果をキャッシュできるように、コントローラアクションのフィルタとして [[yii\filters\HttpCache]] を設定します。[[yii\filters\HttpCache]] は `GET` と `HEAD` リクエストに対してのみ動作し、また、それらのリクエストは 3 種類のキャッシュ関連の HTTP ヘッダを扱うことができます:
* [[yii\filters\HttpCache::lastModified|Last-Modified]]
* [[yii\filters\HttpCache::etagSeed|Etag]]
* [[yii\filters\HttpCache::cacheControlHeader|Cache-Control]]
## `Last-Modified` ヘッダ <a name="last-modified"></a>
`Last-Modified` ヘッダは、クライアントがそれをキャッシュする時から、ページが変更されたかどうかを示すために、タイムスタンプを使用しています。
`Last-Modified` ヘッダの送信を有効にするには [[yii\filters\HttpCache::lastModified]] プロパティを、ページの変更時間に関する UNIX タイムスタンプを返す PHP の callable 型で、以下のようなシグネチャで構成していきます。
```php
/**
* @param Action $action 現在扱っているアクションオブジェクト
* @param array $params "params" プロパティの値
* @return integer ページの更新時刻を表す UNIX タイムスタンプ
*/
function ($action, $params)
```
以下は `Last-Modified` ヘッダを使用する例です:
```php
public function behaviors()
{
return [
[
'class' => 'yii\filters\HttpCache',
'only' => ['index'],
'lastModified' => function ($action, $params) {
$q = new \yii\db\Query();
return $q->from('post')->max('updated_at');
},
],
];
}
```
上記のコードは `index` アクションでのみ HTTP キャッシュを有効にしている状態です。投稿の最終更新時刻に基づいて `Last-Modified` を生成する必要があります。ブラウザが初めて `index` ページにアクセスすると、ページはサーバ上で生成されブラウザに送信されます。もしブラウザが再度同じページにアクセスし、その期間中に投稿に変更がない場合は、ブラウザはクライアントサイドにキャッシュしたものを使用するので、サーバはページを再生成することはありません。その結果、サーバサイドのレンダリング処理とページコンテンツの送信は両方ともスキップされます。
## `ETag` ヘッダ <a name="etag"></a>
"Entity Tag" (略して `ETag`) ヘッダはページコンテンツを表すためにハッシュを使用します。ページが変更された場合ハッシュも同様に変更されます。サーバサイドで生成されたハッシュとクライアントサイドで保持しているハッシュを比較することによって、ページが変更されたかどうか、また再送信するべきかどうかを決定します。
`ETag` ヘッダの送信を有効にするには [[yii\filters\HttpCache::etagSeed]] プロパティを設定します。プロパティは ETag のハッシュを生成するためのシードを返す PHP の callable 型で、以下のようなシグネチャで構成していきます。
```php
/**
* @param Action $action 現在扱っているアクションオブジェクト
* @param array $params "params" プロパティの値
* @return string ETag のハッシュを生成するためのシードとして使用する文字列
*/
function ($action, $params)
```
以下は `ETag` ヘッダを使用している例です:
```php
public function behaviors()
{
return [
[
'class' => 'yii\filters\HttpCache',
'only' => ['view'],
'etagSeed' => function ($action, $params) {
$post = $this->findModel(\Yii::$app->request->get('id'));
return serialize([$post->title, $post->content]);
},
],
];
}
```
上記のコードは `view` アクションでのみ HTTP キャッシュを有効にしている状態です。リクエストされた投稿のタイトルとコンテンツに基づいて HTTP の `Etag` ヘッダを生成しています。ブラウザが初めて `view` ページにアクセスするときに、ページがサーバ上で生成されブラウザに送信されます。ブラウザが再度同じページにアクセスし、投稿のタイトルやコンテンツに変更がない場合には、サーバはページを再生成せず、ブラウザはクライアントサイトにキャッシュしたものを使用します。その結果、サーバサイドのレンダリング処理とページコンテンツ送信の両方ともスキップされます。
ETag は `Last-Modified` ヘッダよりも複雑かつ、より正確なキャッシング方式を可能にします。例えば、サイトが別のテーマに切り替わった場合には ETag を無効化する、といったことができます。
ETag はリクエスト毎に再評価する必要があるため、負荷の高いもの生成すると `HttpCache` の本来の目的を損なって不必要なオーバーヘッドが生じる場合があるので、ページのコンテンツが変更されたときにキャッシュを無効化するための式は単純なものを指定するようにして下さい。
> 注意: [RFC 7232](http://tools.ietf.org/html/rfc7232#section-2.4) に準拠して `Etag` と `Last-Modified` ヘッダの両方を設定した場合、`HttpCache` はその両方とも送信します。また、もし `If-None-Match` ヘッダと `If-Modified-Since` ヘッダの両方を送信した場合は前者のみが尊重されます。
## `Cache-Control` ヘッダ <a name="cache-control"></a>
`Cache-Control` ヘッダはページのための一般的なキャッシュポリシーを指定します。ヘッダ値に [[yii\filters\HttpCache::cacheControlHeader]] プロパティを設定することで、それを送ることができます。デフォルトでは、以下のヘッダーが送信されます:
```
Cache-Control: public, max-age=3600
```
## セッションキャッシュリミッタ<a name="session-cache-limiter"></a>
ページでセッションを使用している場合、PHP はいくつかのキャッシュ関連の HTTP ヘッダ(PHP の設定ファイル内で指定されている session.cache_limiter など)を自動的に送信します。これらのヘッダは `HttpCache` で妨害したり、必要なキャッシュを無効にしたりできます。この動作を変更したい場合は [[yii\filters\HttpCache::sessionCacheLimiter]] プロパティを設定します。プロパティには `public`、`private`、`private_no_expire`、そして `nocache` などの文字列の値を使用することができます。これらの値についての説明は [session_cache_limiter()](http://www.php.net/manual/ja/function.session-cache-limiter.php) を参照してください。
## SEO への影響 <a name="seo-implications"></a>
検索エンジンのボットはキャッシュヘッダを尊重する傾向があります。 クローラの中には、一定期間内に処理するドメインごとのページ数に制限を持っているものもあるため、キャッシュヘッダを導入して、処理の必要があるページ数を減らしてやると、サイトのインデックスの作成を促進できるかも知れません。
docs/guide-ja/caching-overview.md 0 → 100644
キャッシュ
=======
ウェブアプリケーションのパフォーマンスを向上させるための簡単で効果的な方法としてキャッシュというものがあります。比較的静的なデータをキャッシュに格納し、必要に応じてキャッシュからそれらを取得することによって、アプリケーションは一からデータを生成するのに必要な時間を節約することができます。
キャッシュはさまざまなレベルのものを、アプリケーション内のさまざまな場所で使用することができます。例えばサーバサイドでの低いレベルでは、データベースから取得した最新の記事情報リストのような基本的なデータを格納するために使用したり、高いレベルでは、レンダリング結果の一部分、最新の記事であったり、またウェブページ全体を格納するためなどにも使用できます。クライアントサイドでは、ブラウザのキャッシュに最近訪れたことのあるページの内容を格納するために HTTP キャッシュを使用することもできます。
Yii では以下のリストに挙げられているキャッシュ機構をサポートしています:
* [データキャッシュ](caching-data.md)
* [フラグメントキャッシュ](caching-fragment.md)
* [ページキャッシュ](caching-page.md)
* [HTTP キャッシュ](caching-http.md)
docs/guide-ja/caching-page.md 0 → 100644
ページキャッシュ
============
ページキャッシュはサーバサイドでページ全体のコンテンツをキャッシュすることを言います。あとで、同じページに再度リクエストがあった場合、その内容を一から再び生成させるのではなく、キャッシュから提供するようにします。
ページキャッシュは [[yii\filters\PageCache]]、 [アクションフィルタ](structure-filters.md) によってサポートされています。これは、コントローラクラスで以下のように使用することができます：
```php
public function behaviors()
{
return [
[
'class' => 'yii\filters\PageCache',
'only' => ['index'],
'duration' => 60,
'variations' => [
\Yii::$app->language,
],
'dependency' => [
'class' => 'yii\caching\DbDependency',
'sql' => 'SELECT COUNT(*) FROM post',
],
],
];
}
```
上記のコードは、ページキャッシュが `index` アクションのみで使用され、そのページのコンテンツは最大 60 秒間キャッシュし、現在のアプリケーションの言語によって変化し、投稿の総数に変化があった場合キャッシュされたページが無効になる、ということを示しています。
見てわかるように、ページキャッシュは [フラグメントキャッシュ](caching-fragment.md) ととてもよく似ています。それらは両方とも `duration`、`dependencies`、`variations`、そして `enabled` などのオプションをサポートしています。主な違いとしては、ページキャッシュは [アクションフィルタ](structure-filters.md) として、フラグメントキャッシュは [ウィジェット](structure-widgets.md) として実装されているということです。
また、ページキャッシュと一緒に [ダイナミックコンテンツ](caching-fragment.md#dynamic-content) だけでなく [フラグメントキャッシュ](caching-fragment.md) も使用することができます。
docs/guide-ja/images/application-lifecycle.png
docs/guide-ja/images/application-lifecycle.png

39.4 KB | W: 0px | H: 0px

docs/guide-ja/images/application-lifecycle.png

37.8 KB | W: 0px | H: 0px

  • 2-up
  • Swipe
  • Onion skin
docs/guide-ja/images/application-structure.png
docs/guide-ja/images/application-structure.png

24.2 KB | W: 0px | H: 0px

docs/guide-ja/images/application-structure.png

22 KB | W: 0px | H: 0px

  • 2-up
  • Swipe
  • Onion skin
docs/guide-ja/intro-upgrade-from-v1.md
......@@ -45,7 +45,7 @@ Yii 2.0 縺ｯ PHP 5.4 莉･荳翫ｒ蠢ｦ√→縺励∪縺吶１HP 5.4 縺ｯ縲〆ii 1.1 縺ｫ繧医
Yii 2.0 での最も明らかな変更は名前空間の使用です。
ほとんど全てのコアクラスが、例えば、`yii\web\Request` のように名前空間に属します。
クラス名に "C" のプレフィックスはもう使われません。
クラス名に "C" の接頭辞はもう使われません。
命名のスキームはディレクトリ構造に従うようになりました。
例えば、`yii\web\Request` は、対応するクラスファイルが Yii フレームワークフォルダの下の `web/Request.php` であることを示します。
......@@ -151,12 +151,12 @@ Yii 2.0 縺ｯ縲√ヱ繧ｹ繧ｨ繧､繝ｪ繧｢繧ｹ縺ｮ菴ｿ逕ｨ繧偵√ヵ繧｡繧､繝ｫ/繝ぅ繝ｬ繧ｯ繝医
------
Yii 2 のビューについての最も顕著な変更は、ビューの中で `$this` という特殊な変数がカレントコントローラやウィジェットを指すものではなくなったということです。
今や `$this` は 2.0 で新しく導入された概念である *ビュー*オブジェクトを指します。
*ビュー*オブジェクトは [[yii\web\View]] という型であり、MVC パターンのビューの部分を表すものです。
今や `$this` は 2.0 で新しく導入された概念である *ビュー* オブジェクトを指します。
*ビュー* オブジェクトは [[yii\web\View]] という型であり、MVC パターンのビューの部分を表すものです。
ビューにおいてコントローラやウィジェットにアクセスしたい場合は、`$this->context` を使うことが出来ます。
パーシャルビューを別のビューの中で表示するためには、`$this->renderPartial()` ではなく、`$this->render()` を使います。
`render` の呼び出しは、2.0 では明示的に echo しなくてはなりません。と言うのは、`render)` メソッドは、直接に表示するのではなく、レンダリング結果を文字列として返すものだからです。
`render` の呼び出しは、2.0 では明示的に echo しなくてはなりません。と言うのは、`render()` メソッドは、直接に表示するのではなく、レンダリング結果を文字列として返すものだからです。
例えば:
```php
......@@ -176,8 +176,8 @@ Yii 2.0 縺ｯ [[yii\base\Model]] 繧 1.1 縺ｫ縺翫¢繧 `CModel` 縺ｨ蜷梧ｧ倥↑蝓ｺ蠎輔
`CFormModel` というクラスは完全に廃止されました。
Yii 2 では、それの代りに、[yii\base\Model]] を拡張してフォームモデルクラスを作成すべきです。
Yii 2.0 は シナリオを宣言するための [[yii\base\Model::scenarios()|scenarios()]] というメソッドを導入しました。
このメソッドを使って、どのようなシナリオがサポートされるか、また、どのシナリオの下である属性が検証される必要があるか、安全とみなされるか否か、などを宣言します。
Yii 2.0 は サポートされるシナリオを宣言するための [[yii\base\Model::scenarios()|scenarios()]] というメソッドを導入しました。
このメソッドを使って、あるシナリオの下で、どの属性が検証される必要があるか、また、どの属性が安全とみなされるか否か、などを宣言することが出来ます。
例えば:
```php
......@@ -193,12 +193,12 @@ public function scenarios()
上記では二つのシナリオが宣言されています: `backend` と `frontend` です。
`backend` シナリオでは、`email` と `role` の属性が両方とも安全であり、一括代入が可能です。
`frontend` シナリオでは、`email` は一括代入が可能ですが、`role` は不可能です。
`email` と `role` は、両方とも、ルールを使って検証されなければなりません。
`email` と `role` は、両方とも、規則を使って検証されなければなりません。
[[yii\base\Model::rules()|rules()]] メソッドが Yii 1.1 同様に検証ルールを宣言するために使われます。
[[yii\base\Model::rules()|rules()]] メソッドが Yii 1.1 同様に検証規則を宣言するために使われます。
[[yii\base\Model::scenarios()|scenarios()]] が導入されたことにより、`unsafe` バリデータが無くなったことに注意してください。
ほとんどの場合、[[yii\base\Model::rules()|rules()]] メソッドが存在し得るシナリオを十全に記述することが出来るなら、そして `unsafe` な属性を宣言する必要が無いなら、[[yii\base\Model::scenarios()|scenarios()]] をオーバーライドする必要はありません。
ほとんどの場合、[[yii\base\Model::rules()|rules()]] メソッドが在り得るシナリオを十分に既定しているなら、そして `unsafe` な属性を宣言する必要が無いなら、[[yii\base\Model::scenarios()|scenarios()]] をオーバーライドする必要はありません。
モデルについてさらに詳細を学習するために、[モデル](structure-models.md) の節を参照してください。
......@@ -389,7 +389,7 @@ $sql = $command->sql;
$rows = $command->queryAll();
```
何より良いのは、このようなクエリ構築メソッドが [Active Record](db-active-record.md) を扱う時にも使える、ということです。
何より良いのは、このようなクエリ構築メソッドが [アクティブレコード](db-active-record.md) を扱う時にも使える、ということです。
更なる詳細については [クエリビルダ](db-query-builder.md) の節を参照してください。
......@@ -397,7 +397,7 @@ $rows = $command->queryAll();
アクティブレコード
------------------
Yii 2.0 は [Active Record](db-active-record.md) に数多くの変更を導入しました。
Yii 2.0 は [アクティブレコード](db-active-record.md) に数多くの変更を導入しました。
最も顕著な違いは、クエリの構築方法とリレーショナルクエリの処理の二つです。
1.1 の `CDbCriteria` クラスは Yii 2 では [[yii\db\ActiveQuery]] に置き換えられました。
......
docs/guide-ja/intro-yii.md
......@@ -19,7 +19,7 @@ Yii を他のフレームワークと比べるとどうか?
あなたが既に他のフレームワークに親しんでいる場合は、Yii を比較するとどうなるのかを知りたいと思うでしょう:
- ほとんどの PHP フレームワーク同様、Yii は MVC (Model-View-Controller) デザインパターンを実装し、このパターンに基いたコードの組織化を促進しています。
- ほとんどの PHP フレームワーク同様、Yii は MVC (Model-View-Controller) デザインパターンを実装し、このパターンに基づいたコードの組織化を促進しています。
- Yii は、コードはシンプルかつエレガントに書かれるべきである、という哲学を採用しています。
Yii は、何らかのデザインパターンを厳密に守ることを主たる目的として大袈裟な設計をすることは、決してしようとしません。
- Yii は、検証済みで直ちに使える多数の機能を提供するフル装備のフレームワークです:
......
docs/guide-ja/start-databases.md
......@@ -127,7 +127,7 @@ $country->save();
```
> Info|情報: アクティブレコードは、オブジェクト指向の流儀でデータベースのデータにアクセスし、操作する強力な方法です。
[Active Record](db-active-record.md) の節で、更に詳細な情報を得ることが出来ます。
[アクティブレコード](db-active-record.md) の節で、更に詳細な情報を得ることが出来ます。
もう一つの方法として、[データアクセスオブジェクト(DAO)](db-dao.md) と呼ばれる、より低レベルなデータアクセス方法を使って
データベースを操作することも出来ます。
......@@ -184,7 +184,7 @@ class CountryController extends Controller
* クエリによって表現される SQL 文に `offset` 句と `limit` 句をセットして、一度に一ページ分のデータだけ (1ページ最大5行)を返すようにします。
* 次の項で説明されるように、一連のページボタンからなるページャをビューに表示するために使われます。
コードの最後で、`index` アクションは `index` と言う名前のビューを表示していますが、このとき、国データはもちろん、そのページ付け情報もビューに渡されます。
コードの最後で、`index` アクションは `index` と言う名前のビューをレンダリングしていますが、このとき、国データはもちろん、そのページ付け情報もビューに渡されます。
ビューを作成する<a name="creating-view"></a>
......@@ -213,8 +213,9 @@ use yii\widgets\LinkPager;
```
ビューは国データの表示に関連して二つの部分に分けられます。
最初の部分では、提供された国データが HTML の順序無しリストとして表示されます。
第二の部分では、アクションから渡されたページ付け情報を使って、[[yii\widgets\LinkPager]] ウィジェットが表示されます。
最初の部分では、提供された国データがたどられて、HTML の順序無しリストとしてレンダリングされます。
第二の部分では、アクションから渡されたページ付け情報を使って、[[yii\widgets\LinkPager]]
ウィジェットがレンダリングされます。
`LinkPager` ウィジェットはページボタンのリストを表示します。ボタンのどれかをクリックすると、対応するページの国データが更新表示されます。
......@@ -243,7 +244,7 @@ http://hostname/index.php?r=country/index&page=2
* 最初、[[yii\data\Pagination|Pagination]] は、1ページ目を表しています。
これは、国の SELECT クエリが `LIMIT 5 OFFSET 0` という句を伴うことを示しています。
その結果、最初の5つの国が取得されて表示されます。
* [[yii\widgets\LinkPager|LinkPager]] ウィジェットは、[[yii\data\Pagination::createUrl()|Pagination]] によって作成された URL を使ってページボタンを表示します。
* [[yii\widgets\LinkPager|LinkPager]] ウィジェットは、[[yii\data\Pagination::createUrl()|Pagination]] によって作成された URL を使ってページボタンをレンダリングします。
URL は、別々のページ番号を表現する `page` というクエリパラメータを含んだものになります。
* ページボタン "2" をクリックすると、`country/index` のルートに対する新しいリクエストが発行され、処理されます。
[[yii\data\Pagination|Pagination]] が URL から `page` クエリパラメータを読み取って、カレントページ番号を 2 にセットします。
......
docs/guide-ja/start-forms.md
......@@ -172,7 +172,7 @@ use yii\widgets\ActiveForm;
```
このビューは HTML フォームを構築するのに、[[yii\widgets\ActiveForm|ActiveForm]] と呼ばれる強力な [ウィジェット](structure-widgets.md) を使います。
ウィジェットの `begin()` メソッドと `end()` メソッドが、それぞれ、フォームの開始タグと終了タグを表示します。
ウィジェットの `begin()` メソッドと `end()` メソッドが、それぞれ、フォームの開始タグと終了タグをレンダリングします。
この二つのメソッドの呼び出しの間に、[[yii\widgets\ActiveForm::field()|field()]] メソッドによって入力フィールドが作成されます。
最初の入力フィールドは "name" のデータ、第二の入力フィールドは "email" のデータのためのものです。
入力フィールドの後に、[[yii\helpers\Html::submitButton()]] メソッドが呼ばれて、送信ボタンを生成しています。
......
docs/guide-ja/start-gii.md
......@@ -46,7 +46,7 @@ defined('YII_ENV') or define('YII_ENV', 'dev');
http://hostname/index.php?r=gii
```
> Note|注意: ローカルホスト以外のマシンから GII にアクセスしようとすると、既定ではセキュリティ上の
> Note|注意: ローカルホスト以外のマシンから Gii にアクセスしようとすると、既定ではセキュリティ上の
> 目的からアクセスが拒否されます。下記のように Gii を構成して、許可される IP アドレスを追加することが出来ます。
>
```php
......
docs/guide-ja/start-hello.md
......@@ -4,14 +4,14 @@
この節では、アプリケーションに新しい「こんにちは」というページを作成する方法を説明します。
この目的を達するために、[アクション](structure-controllers.md#creating-actions) と [ビュー](structure-views.md) を作成することになります:
* アプリケーションがこのページへのリクエストをそのアクションに送致(dispatch)し、
* アプリケーションがこのページへのリクエストをそのアクションに送付し、
* 次にそのアクションが "Hello" という言葉をエンドユーザに示すビューを表示します。
このチュートリアルを通じて、次の三つのことを学びます:
1. リクエストに応える [アクション](structure-controllers.md) をどのようにして作るか、
2. レスポンスの内容を構成する [ビュー](structure-views.md) をどのようにして作るか、そして、
3. アプリケーションはどのようにしてリクエストを [アクション](structure-controllers.md#creating-actions) に送致するか。
3. アプリケーションはどのようにしてリクエストを [アクション](structure-controllers.md#creating-actions) に送付するか。
アクションを作成する<a name="creating-action"></a>
......@@ -48,31 +48,31 @@ class SiteController extends Controller
```
上記のコードで、`say` アクションは `SiteController` クラスの中で `actionSay` という名前のメソッドとして定義されています。
Yii はコントローラクラスの中でアクションのメソッドとアクションでないメソッドを区別するために、`action` という接頭語を使います。
`action` という接頭語の後の名前がアクション ID にマップされます。
Yii はコントローラクラスの中でアクションのメソッドとアクションでないメソッドを区別するために、`action` という接頭辞を使います。
`action` という接頭辞の後の名前がアクション ID にマップされます。
アクションを命名するについては、Yii がアクション ID をどのように取り扱うかを知っているべきです。
アクション ID は常に小文字で参照されます。
アクション ID が複数の単語を必要とするときは、単語がダッシュ(-)で連結されます (例えば、`create-comment`)。
アクションメソッドの名前は、アクション ID からダッシュを全て削除し、各単語の先頭の文字を大文字にした結果に `action` という接頭語を付けたものとします。
アクションメソッドの名前は、アクション ID からダッシュを全て削除し、各単語の先頭の文字を大文字にした結果に `action` という接頭辞を付けたものとします。
例えば、アクション ID `create-comment` に対応するアクションメソッド名は `actionCreateComment` となります。
私たちの例では、このアクションメソッドは `$message` というパラメータを取ります。
そして、このパラメータは `"Hello"` という既定値を取ります
(PHP で関数やメソッドの引数について既定値をセットするのと全く同じ方法を使います)。
アプリケーションは、リクエストを受け取って、当該リクエストの処理を `say` アクションに任せると決定した場合、リクエストの中に同じ名前の付いたパラメータがあれば、それをこのパラメータに代入します。
言い換えれば、もしリクエストに `"GoodBye"` という値の `message` パラメータが入っていれば、アクションの `$message` 変数にその値が割り当てけられます。
言い換えれば、もしリクエストに `"GoodBye"` という値の `message` パラメータが入っていれば、アクションの `$message` 変数にその値が割り当てられます。
このアクションメソッドの中では、[[yii\web\Controller::render()|render()]] が呼ばれて `say` と言う名前の [ビュー](structure-views.md) ファイルが表示されます。
このアクションメソッドの中では、[[yii\web\Controller::render()|render()]] が呼ばれて `say` と言う名前の [ビュー](structure-views.md) ファイルがレンダリングされます。
`message` パラメータも同時にビューに渡され、そこで使用されます。
表示結果はアクションメソッドによって返されます。
レンダリング結果はアクションメソッドによって返されます。
返された結果はアプリケーションによって受け取られ、ブラウザ上でエンドユーザに(完全な HTML ページの一部として)表示されます。
ビューを作成する<a name="creating-view"></a>
----------------
[ビュー](structure-views.md) は、レスポンスのコンテンツを生成するために書くスクリプトです。
[ビュー](structure-views.md) は、レスポンスのコンテンツを生成するためにあなたが書くスクリプトです。
「こんにちは」のタスクのためには、アクションメソッドから受け取った `message` パラメータを印字する `say` ビューを作成します:
```php
......@@ -126,7 +126,7 @@ URL から `message` パラメータを省略すると、"Hello" だけを表示
> Info|情報: アクションと同じく、コントローラもまたアプリケーションの中で一意に定義される ID を持ちます。
コントローラ ID も、アクション ID と同じ命名規則を使います。
コントローラクラスの名前は、コントローラ ID からダッシュを削除し、各単語の最初の文字を大文字にし、結果として出来る文字列に `Controller` という接尾語を追加したものとします。
コントローラクラスの名前は、コントローラ ID からダッシュを削除し、各単語の最初の文字を大文字にし、結果として出来る文字列に `Controller` という接尾辞を追加したものとします。
例えば、`post-comment` というコントローラ ID に対応するコントローラクラスの名前は `PostCommentController` です。
......
docs/guide-ja/start-installation.md
......@@ -35,9 +35,9 @@ Composer がインストールされたら、ウェブからアクセスでき
必要なら別のディレクトリ名を選ぶことも出来ます。
> Note|注意: インストール実行中に Composer が あなたの Github アカウントの認証情報を尋ねてくることがあるかも知れません。
> これは、Comoser が Github API の帯域制限にひっかかったためです。
> これは、Comoser が Github API の転送レート制限にひっかかったためです。
> Composer は全てのパッケージのための大量の情報を Github から読み出さなければならないので、こうなるのは普通のことです。
> Github にログインすると API の帯域制限が緩和され、Composer が仕事を続けることが出来るようになります。
> Github にログインすると API の転送レート制限が緩和され、Composer が仕事を続けることが出来るようになります。
> 更なる詳細については、[Composer documentation](https://getcomposer.org/doc/articles/troubleshooting.md#api-rate-limit-and-oauth-tokens) を参照してください。
> Tip|ヒント: Yii の最新の開発バージョンをインストールしたい場合は、[stability option](https://getcomposer.org/doc/04-schema.md#minimum-stability) を追加した次のコマンドを代りに使うことが出来ます:
......@@ -157,7 +157,8 @@ DocumentRoot "path/to/basic/web"
### 推奨される Nginx の構成<a name="recommended-nginx-configuration"></a>
[Nginx](http://wiki.nginx.org/) を使うためには、PHP を [FPM SAPI](http://jp1.php.net/install.fpm) としてインストールしていなければなりません。
下記の設定を使い、`path/to/basic/web` の部分を `basic/web` の実際のパスに置き換え、`mysite.local` を実際のサーバのホスト名に置き換えてください。
下記の設定を使うことができます (`path/to/basic/web` の部分を `basic/web` の実際のパスに置き換え、
`mysite.local` を実際のサーバのホスト名に置き換えてください)。
```
server {
......
docs/guide-ja/start-looking-ahead.md
......@@ -10,20 +10,20 @@ Gii をコード生成に使うと、ウェブ開発のプロセスの大部分
この節では、Yii フレームワークを使うときの生産性を更に高めるために利用できるリソースについてまとめます。
* ドキュメンテーション
- 公式ガイド:
- [公式ガイド](http://www.yiiframework.com/doc-2.0/guide-README.html):
Definitive(最も確実な) という名前が示すように、このガイドは Yii がどのように動作すべきものかを正確に記述し、
Yii を使用するについての全般的な手引きを提供するものです。
これは唯一最重要な Yii のチュートリアルであり、Yii のコードを少しでも書く前に読むべきものです。
- クラスリファレンス:
- [クラスリファレンス](http://www.yiiframework.com/doc-2.0/index.html):
これは Yii によって提供される全てのクラスの使用法を記述しています。
主として、コードを書いている時に、特定のクラス、メソッド、プロパティについて理解したい場合に読まれるべきものです。
クラスリファレンスの使用は、フレームワーク全体の文脈的な理解が出来てからにするのが最善です。
- Wiki の記事:
- [Wiki の記事]((http://www.yiiframework.com/wiki/?tag=yii2)):
Wiki の記事は、Yii のユーザが自身の経験に基づいて書いたものです。
ほとんどの記事は、料理本のレシピのように書かれており、特定の問題を Yii を使って解決する方法を示しています。
これらの記事の品質は公式ガイドほどには良くないかもしれませんが、
より広範なトピックをカバーしていることと、たいていは即座に使えるソリューションを提供してくれることにおいて有用なものです。
- 本
- [書籍](http://www.yiiframework.com/doc/)
* [エクステンション](http://www.yiiframework.com/extensions/):
Yii は、ユーザによって作られた数千におよぶエクステンションのライブラリを誇りとしています。
エクステンションはあなたのアプリケーションに簡単に組み込むことが出来、そうすることでアプリケーションの開発作業をより一層速くて簡単なものにします。
......
docs/guide-ja/start-workflow.md
......@@ -69,7 +69,7 @@ Yii は [モデル・ビュー・コントローラ (MVC)](http://wikipedia.org/
各アプリケーションは一つのエントリスクリプト `web/index.php` を持ちます。これはアプリケーション中で唯一ウェブからアクセス可能な PHP スクリプトです。
エントリスクリプトは入力されたリクエストを受け取って、[アプリケーション](structure-applications.md) のインスタンスを作成します。
[アプリケーション](structure-applications.md) は [コンポーネント](concept-components.md) の助力を得てリクエストを解決し、リクエストを MVC 要素に対して送出します。
[アプリケーション](structure-applications.md) は [コンポーネント](concept-components.md) の助力を得てリクエストを解決し、リクエストを MVC に送付します。
[ウィジェット](structure-widgets.md) は、複雑で動的なユーザインタフェイス要素を構築するために、[ビュー](structure-views.md) の中で使われます。
......@@ -78,7 +78,7 @@ Yii は [モデル・ビュー・コントローラ (MVC)](http://wikipedia.org/
次の図は、アプリケーションがどのようにリクエストを処理するかを示すものです。
![リクエストのライフサイクル](images/application-lifecycle.png)
![リクエストのライフサイクル](images/request-lifecycle.png)
1. ユーザが [エントリスクリプト](structure-entry-scripts.md) `web/index.php` に対してリクエストを出します。
2. エントリスクリプトはアプリケーションの [コンフィギュレーション](concept-configurations.md) を読み出して、
......@@ -90,7 +90,7 @@ Yii は [モデル・ビュー・コントローラ (MVC)](http://wikipedia.org/
6. 一つでもフィルタが失敗したときは、アクションはキャンセルされます。
7. すべてのフィルタを通ったとき、アクションが実行されます。
8. アクションはデータモデルを、おそらくはデータベースから、読み出します。
9. アクションはデータモデルをビューに提供して、ビューを表示します。
10. 表示された結果が [レスポンス](runtime-responses.md) アプリケーションコンポーネントに返されます。
11. レスポンスコンポーネントが表示された結果をユーザのブラウザに送信します。
9. アクションはデータモデルをビューに提供して、ビューをレンダリングします。
10. レンダリング結果が [レスポンス](runtime-responses.md) アプリケーションコンポーネントに返されます。
11. レスポンスコンポーネントがレンダリング結果をユーザのブラウザに送信します。
docs/guide-ja/structure-application-components.md 0 → 100644
アプリケーションコンポーネント
==============================
アプリケーションは [サービスロケータ](concept-service-locator.md) です。
アプリケーションは、リクエストを処理するためのいろいろなサービスを提供する一連のオブジェクト、いわゆる *アプリケーションコンポーネント* をホストします。
例えば、`urlManager` がウェブリクエストを適切なコントローラにルーティングする役割を負い、
`db` コンポーネントが DB 関連のサービスを提供する、等々です。
全てのアプリケーションコンポーネントは、それぞれ、同一のアプリケーション内で他のアプリケーションコンポーネントから区別できるように、ユニークな ID を持ちます。
アプリケーションコンポーネントには、次の式によってアクセス出来ます:
```php
\Yii::$app->componentID
```
例えば、`\Yii::$app->db` を使って、アプリケーションに登録された [[yii\db\Connection|DB 接続]] を取得することが出来ます。
また、`\Yii::$app->cache` を使って、[[yii\caching\Cache|プライマリキャッシュ]] を取得できます。
アプリケーションコンポーネントは、上記の式を使ってアクセスされた最初の時に作成されます。
二度目以降のアクセスでは、同じコンポーネントのインスタンスが返されます。
どのようなオブジェクトでも、アプリケーションコンポーネントとすることが可能です。
[アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の中で [[yii\base\Application::components]] プロパティを構成することによって、アプリケーションコンポーネントを登録することが出来ます。
例えば、
```php
[
'components' => [
// クラス名を使って "cache" コンポーネントを登録
'cache' => 'yii\caching\ApcCache',
// コンフィギュレーション配列を使って "db" コンポーネントを登録
'db' => [
'class' => 'yii\db\Connection',
'dsn' => 'mysql:host=localhost;dbname=demo',
'username' => 'root',
'password' => '',
],
// 無名関数を使って "search" コンポーネントを登録
'search' => function () {
return new app\components\SolrService;
},
],
]
```
> Info|情報: 必要なだけ多くのアプリケーションコンポーネントを登録することが出来ますが、慎重にしなければなりません。
アプリケーションコンポーネントはグローバル変数のようなものです。あまり多くのアプリケーションコンポーネントを使うと
コードのテストと保守が困難になるおそれがあります。
多くの場合、必要なときにローカルなコンポーネントを作成して使用するだけで十分です。
## コンポーネントをブートストラップに含める<a name="bootstrapping-components"></a>
上述のように、アプリケーションコンポーネントは最初にアクセスされた時に初めてインスタンスが作成されます。
リクエストの間に全くアクセスされなかった時は、インスタンスは作成されません。けれども、場合によっては、
明示的にアクセスされないときでも、リクエストごとにアプリケーションコンポーネントのインスタンスを作成する必要がある
ことがあります。そうするためには、アプリケーションの [[yii\base\Application::bootstrap|bootstrap]] プロパティのリストに
そういうコンポーネントの ID を挙げることが出来ます。
例えば、次のアプリケーションコンフィギュレーションは、`log` コンポーネントが常にロードされることを保証するものです:
```php
[
'bootstrap' => [
'log',
],
'components' => [
'log' => [
// "log" コンポーネントのコンフィギュレーション
],
],
]
```
## コアアプリケーションコンポーネント<a name="core-application-components"></a>
Yii は固定の ID とデフォルトのコンフィギュレーションを持つ一連の *コア* アプリケーションコンポーネントを定義しています。
例えば、[[yii\web\Application::request|request]] コンポーネントは、ユーザリクエストに関する情報を収集し、
それを [ルート](runtime-routing.md) として解決します。
[[yii\base\Application::db|db]] コンポーネントは、それを通じてデータベースクエリを実行できるデータベース接続を表現します。
Yii のアプリケーションがユーザリクエストを処理することが出来るのは、まさにこれらのコアアプリケーションコンポーネントの助力によります。
下記が事前に定義されたコアアプリケーションコンポーネントです。
通常のアプリケーションコンポーネントに対するのと同様に、これらを構成し、カスタマイズすることが出来ます。
コアアプリケーションコンポーネントを構成するときは、クラスを指定しなければ、デフォルトのクラスが使用されます。
* [[yii\web\AssetManager|assetManager]]: アセットバンドルとアセットの発行を管理します。
更なる詳細は [アセットを管理する](structure-assets.md) の節を参照してください。
* [[yii\db\Connection|db]]: データベース接続を表します。これを通じて、DB クエリを実行することが出来ます。
このコンポーネントを構成するときは、コンポーネントのクラスはもちろん、
[[yii\db\Connection::dsn]] のような必須のコンポーネントプロパティを指定しなければならないことに注意してください。
更なる詳細は [データアクセスオブジェクト (DAO)](db-dao.md) の節を参照してください。
* [[yii\base\Application::errorHandler|errorHandler]]: PHP のエラーと例外を処理します。
更なる詳細は [エラー処理](runtime-handling-errors.md) の節を参照してください。
* [[yii\i18n\Formatter|formatter]]: エンドユーザに表示されるデータに書式を設定します。
例えば、数字が3桁ごとの区切りを使って表示されたり、日付が長い書式で表示されたりします。
更なる詳細は [データの書式設定](output-formatter.md) の節を参照してください。
* [[yii\i18n\I18N|i18n]]: メッセージの翻訳と書式設定をサポートします。
更なる詳細は [国際化](tutorial-i18n.md) の節を参照してください。
* [[yii\log\Dispatcher|log]]: ログの対象を管理します。
更なる詳細は [ログ](runtime-logging.md) の節を参照してください。
* [[yii\swiftmailer\Mailer|mail]]: メールの作成と送信をサポートします。
更なる詳細は [メール](tutorial-mailing.md) の節を参照してください。
* [[yii\base\Application::response|response]]: エンドユーザに送信されるレスポンスを表現します。
更なる詳細は [レスポンス](runtime-responses.md) の節を参照してください。
* [[yii\base\Application::request|request]]: エンドユーザから受信したリクエストを表現します。
更なる詳細は [リクエスト](runtime-requests.md) の節を参照してください。
* [[yii\web\Session|session]]: セッション情報を表現します。
このコンポーネントは、[[yii\web\Application|ウェブアプリケーション]] においてのみ利用できます。.
更なる詳細は [セッションとクッキー](runtime-sessions-cookies.md) の節を参照してください。
* [[yii\web\UrlManager|urlManager]]: URL の解析と生成をサポートします。
更なる詳細は [URL の解析と生成](runtime-url-handling.md) の節を参照してください。
* [[yii\web\User|user]]: ユーザの認証情報を表現します。
このコンポーネントは、[[yii\web\Application|ウェブアプリケーション]] においてのみ利用できます。.
更なる詳細は [認証](security-authentication.md) の節を参照してください。
* [[yii\web\View|view]]: ビューのレンダリングをサポートします。
更なる詳細は [ビュー](structure-views.md) の節を参照してください。
docs/guide-pt-BR/start-workflow.md
......@@ -89,7 +89,7 @@ Ciclo de Vida da Requisição <a name="request-lifecycle"></a>
O diagrama a seguir demonstra como uma aplicação gerencia uma requisição.
![Ciclo de Vida da Requisição](images/application-lifecycle.png)
![Ciclo de Vida da Requisição](images/request-lifecycle.png)
1. Um usuário faz uma requisiçao ao [script de entrada](structure-entry-scripts.md) `web/index.php`.
2. O script de entrada carrega a [configuração](concept-configurations.md) da
......
docs/guide-ru/caching-fragment.md
......@@ -29,7 +29,7 @@ if ($this->beginCache($id)) {
### Срок хранения <a name="duration"></a>
Наверное, наиболее часто используемым параметром является [[yii\widgets\FragmentCache::duration|duration]].
Он определяет какое количество секунд содержимое будет оставаться действительным (корректным). Следующий код помещает фрагмент в кэш не более, чем на час::
Он определяет какое количество секунд содержимое будет оставаться действительным (корректным). Следующий код помещает фрагмент в кэш не более, чем на час:
```php
if ($this->beginCache($id, ['duration' => 3600])) {
......@@ -83,7 +83,7 @@ if ($this->beginCache($id, ['variations' => [Yii::$app->language]])) {
### Переключение кэширования <a name="toggling-caching"></a>
Иногда может потребоваться включать кеширование фрагментов только для определённых условий. Например, страницу с формой мы хотим кэшировать только тогда, когда обращение к ней произошло впервые (посредством GET запроса). Любое последующее отображение формы (посредством POST запроса) не должно быть кэшировано, потому что может содержать данные, введённые пользователем. Для этого мы задаём параметр [[yii\widgets\FragmentCache::enabled|enabled]]:
Иногда может потребоваться включать кэширование фрагментов только для определённых условий. Например, страницу с формой мы хотим кэшировать только тогда, когда обращение к ней произошло впервые (посредством GET запроса). Любое последующее отображение формы (посредством POST запроса) не должно быть кэшировано, потому что может содержать данные, введённые пользователем. Для этого мы задаём параметр [[yii\widgets\FragmentCache::enabled|enabled]]:
```php
if ($this->beginCache($id, ['enabled' => Yii::$app->request->isGet])) {
......@@ -117,7 +117,7 @@ if ($this->beginCache($id1)) {
}
```
Параметры кэширования могут быть различными для вложенных кэшей. Например, внутренний и внешний кэши в вышеприведённом примере могут иметь разные сроки хранения. Даже когда данные внешнего кэша уже не являются актуальными, внутренний кеш может содержать актуальный фрагмент. Тем не менее, обратное не верно. Если внешний кэш актуален, данные будут отдаваться из него даже если внутренний кэш содержит устаревшие данные. Следует проявлять осторожность при выставлении срока хранения и задания зависимостей для вложенных кэшей. В противном случае вы можете получить устаревшие данные.
Параметры кэширования могут быть различными для вложенных кэшей. Например, внутренний и внешний кэши в вышеприведённом примере могут иметь разные сроки хранения. Даже когда данные внешнего кэша уже не являются актуальными, внутренний кэш может содержать актуальный фрагмент. Тем не менее, обратное не верно. Если внешний кэш актуален, данные будут отдаваться из него даже если внутренний кэш содержит устаревшие данные. Следует проявлять осторожность при выставлении срока хранения и задания зависимостей для вложенных кэшей. В противном случае вы можете получить устаревшие данные.
## Динамическое содержимое <a name="dynamic-content"></a>
......
docs/guide-ru/caching-http.md
......@@ -104,7 +104,7 @@ Cache-Control: public, max-age=3600
## Ограничитель кэша сессий <a name="session-cache-limiter"></a>
Когда на странице используются сессии, PHP автоматически отправляет некоторые связанные с кэшем HTTP заголовки, определённые в настройке `session.cache_limiter` в php.ini. Эти заголовки могут вмешиваться или отключать кэширование, которое вы ожидаете от `HttpCache`. Чтобы предотвратить эту проблему, по-умолчанию `HttpCache` будет автоматически отключать отправку этих заголовков. Если вы хотите изменить это поведение, вы должны настроить свойство [[yii\filters\HttpCache::sessionCacheLimiter]]. Это свойство может принимать строковое значение, включая `public`, `private`, `private_no_expire` и `nocache`. Пожалуйста, обратитесь к руководству PHP о [session_cache_limiter()](http://www.php.net/manual/en/function.session-cache-limiter.php)
Когда на странице используются сессии, PHP автоматически отправляет некоторые связанные с кэшем HTTP заголовки, определённые в настройке `session.cache_limiter` в php.ini. Эти заголовки могут вмешиваться или отключать кэширование, которое вы ожидаете от `HttpCache`. Чтобы предотвратить эту проблему, по умолчанию `HttpCache` будет автоматически отключать отправку этих заголовков. Если вы хотите изменить это поведение, вы должны настроить свойство [[yii\filters\HttpCache::sessionCacheLimiter]]. Это свойство может принимать строковое значение, включая `public`, `private`, `private_no_expire` и `nocache`. Пожалуйста, обратитесь к руководству PHP о [session_cache_limiter()](http://www.php.net/manual/en/function.session-cache-limiter.php)
для объяснения этих значений.
......
docs/guide-ru/caching-page.md
......@@ -2,7 +2,7 @@
=================
Кэширование страниц — это кэширование всего содержимого страницы на стороне сервера. Позже, когда эта страница
будет снова запрошена, сервер вернет её из кэша вместо того что бы генерировать её заново.
будет снова запрошена, сервер вернет её из кэша вместо того чтобы генерировать её заново.
Кэширование страниц осуществляется при помощи [фильтра действия](structure-filters.md) [[yii\filters\PageCache]] и
может быть использовано в классе контроллера следующим образом:
......@@ -27,7 +27,7 @@ public function behaviors()
}
```
Приведённый код задействует кэширование только для действия `index`. Содержимое страницы кешируется максимум на 60 секунд
Приведённый код задействует кэширование только для действия `index`. Содержимое страницы кэшируется максимум на 60 секунд
и варьируется в зависимости от текущего языка приложения. Кэшированная страница должна быть признана просроченной, если
общее количество постов изменилось.
......
docs/guide-ru/concept-di-container.md
......@@ -98,7 +98,7 @@ $container = new \yii\di\Container;
// регистрация имени класса, как есть. это может быть пропущено.
$container->set('yii\db\Connection');
// регистраци интерфейса
// регистрация интерфейса
// Когда класс зависит от интерфейса, соответствующий класс
// будет использован в качестве зависимости объекта
$container->set('yii\mail\MailInterface', 'yii\swiftmailer\Mailer');
......@@ -172,7 +172,7 @@ $engine = $container->get('app\components\SearchEngine', [$apiKey], ['type' => 1
```
За кулисами, контейнер внедрения зависимостей делает гораздо больше работы, чем просто создание нового объекта.
Прежде всего, контейнер, осмотрит конструктор класса, что бы узнать имя зависимого класса или интерфейса, а затем автоматически разрешит эти зависимости рекурсивно.
Прежде всего, контейнер, осмотрит конструктор класса, чтобы узнать имя зависимого класса или интерфейса, а затем автоматически разрешит эти зависимости рекурсивно.
Следующий код демонстрирует более сложный пример. Класс `UserLister` зависит от объекта, реализующего интерфейс `UserFinderInterface`; класс `UserFinder` реализует этот интерфейс и зависит от
объекта `Connection`. Все эти зависимости были объявлены через тип подсказки параметров конструктора класса.
......@@ -240,7 +240,7 @@ $lister = new UserLister($finder);
Yii создаёт контейнер внедрения зависимостей когда вы подключаете файл `Yii.php` во [входном скрипте](structure-entry-scripts.md)
вашего приложения. Контейнер внедрения зависимостей доступен через [[Yii::$container]]. При вызове [[Yii::createObject()]],
метод на самом деле вызовет метод контейнера [[yii\di\Container::get()|get()]], что бы создать новый объект.
метод на самом деле вызовет метод контейнера [[yii\di\Container::get()|get()]], чтобы создать новый объект.
Как упомянуто выше, контейнер внедрения зависимостей автоматически разрешит зависимости (если таковые имеются) и внедрит их в только что созданный объект.
Поскольку Yii использует [[Yii::createObject()]] в большей части кода своего ядра для создания новых объектов, это означает,
что вы можете настроить глобальные объекты, имея дело с [[Yii::$container]].
......@@ -307,7 +307,7 @@ class HotelController extends Controller
Итог <a name="summary"></a>
-------
Как dependency injection, так и [service locator](concept-service-locator.md) являются популярными паттернами проектирования, которые позволяют
создавать программное обеспечение в слабосвязаной и более тестируемой манере.
создавать программное обеспечение в слабосвязанной и более тестируемой манере.
Мы настоятельно рекомендуем к прочтению
[статью Мартина Фаулера](http://martinfowler.com/articles/injection.html), для более глубокого понимания dependency injection и service locator.
......
docs/guide-ru/intro-upgrade-from-v1.md
......@@ -445,7 +445,7 @@ Yii 2.0 осуществляет жадную загрузку связи не
$customers = Customer::find()->asArray()->all();
```
Ещё одно изменение связано с тем, что вы больше не можете определять значения по-умолчанию через public свойства.
Ещё одно изменение связано с тем, что вы больше не можете определять значения по умолчанию через public свойства.
Вы должны установить их в методе `init` вашего класса, если это требуется.
```php
......
docs/guide-ru/intro-yii.md
......@@ -10,7 +10,7 @@ Yii – это высокопроизводительный компонентн
------------------------------------------
Yii – это универсальный фреймворк и может быть задействован во всех типах веб приложений. Благодаря его компонентной
структуре и отличной поддержке кеширования, фреймворк особенно подходит для разработки таких крупных проектов как
структуре и отличной поддержке кэширования, фреймворк особенно подходит для разработки таких крупных проектов как
порталы, форумы, CMS, магазины или RESTful-приложения.
......@@ -23,7 +23,7 @@ Yii – это универсальный фреймворк и может бы
- Yii придерживается философии простого и элегантного кода не пытаясь усложнять дизайн только ради следования каким-либо
шаблонам проектирования.
- Yii является full-stack фреймворком и включает в себя проверенные и хорошо зарекомендовавшие себя возможности, такие как
ActiveRecord для реляционных и NoSQL баз данных, поддержку REST API, многоуровневое кеширование и другие.
ActiveRecord для реляционных и NoSQL баз данных, поддержку REST API, многоуровневое кэширование и другие.
- Yii отлично расширяем. Вы можете настроить или заменить практически любую часть основного кода. Используя архитектуру расширений легко делиться кодом или использовать код сообщества.
- Одна из главных целей Yii – производительность.
......
docs/guide-ru/rest-quick-start.md
......@@ -5,7 +5,7 @@ Yii включает полноценный набор средств для у
В частности это следующие возможности:
* Быстрое создание прототипов с поддержкой распространенных API к [Active Record](db-active-record.md);
* Настройка формата ответа (JSON и XML реализованы по-умолчанию);
* Настройка формата ответа (JSON и XML реализованы по умолчанию);
* Получение сериализованных объектов с нужной вам выборкой полей;
* Надлежащее форматирование данных и ошибок при их валидации;
* Поддержка [HATEOAS](http://en.wikipedia.org/wiki/HATEOAS);
......
docs/guide-ru/rest-rate-limiting.md
......@@ -18,7 +18,7 @@
Вы можете использовать два столбца в таблице user для хранения количества разрешённых запросов и времени последней проверки.
В методах `loadAllowance()` и `saveAllowance()` можно реализовать чтение и сохранение значений этих столбцов в соответствии
с данными текущего аутентифицированного пользователя. Для улучшения производительности можно попробовать хранить эту
информацию в кеше или NoSQL хранилище.
информацию в кэше или NoSQL хранилище.
Как только соответствующий интерфейс будет реализован в классе identity, Yii начнёт автоматически проверять ограничения
частоты запросов при помощи [[yii\filters\RateLimiter]], фильтра действий для [[yii\rest\Controller]]. При превышении
......
docs/guide-ru/rest-resources.md
......@@ -26,7 +26,7 @@ RESTful API строятся вокруг доступа к *ресурсам*
Вы можете указать какие данные включать в представление ресурса в виде массива путём переопределения методов
[[yii\base\Model::fields()|fields()]] и/или [[yii\base\Model::extraFields()|extraFields()]]. Разница между ними в том,
что первый определяет набор полей которые всегда будут включены в массив, а второй определяет дополнительные поля, которые
что первый определяет набор полей, которые всегда будут включены в массив, а второй определяет дополнительные поля, которые
пользователь может запросить через параметр `expand`:
```
......@@ -36,7 +36,7 @@ http://localhost/users
// вернёт только поля id и email, если они объявлены в методе fields()
http://localhost/users?fields=id,email
// вернёт все поля обявленные в fields() и поле profile если оно указано в extraFields()
// вернёт все поля объявленные в fields() и поле profile если оно указано в extraFields()
http://localhost/users?expand=profile
// вернёт только id, email и profile, если они объявлены в fields() и extraFields()
......
docs/guide-ru/runtime-url-handling.md
......@@ -85,7 +85,7 @@ Url::previous(); // получить ранее сохраненный URL
>**Совет**: чтобы сгенерировать URL с хэштэгом, например `/index.php?r=site/page&id=100#title`, укажите параметр `#` в хелпере таким образом:
`Url::to(['post/read', 'id' => 100, '#' => 'title'])`.
Также существует метод `Url::canonical()` , который позволяет создать [канонический URL](https://en.wikipedia.org/wiki/Canonical_link_element) (статья на англ., перевода пока нет) для текущего действия. Этот метод при создании игнорирует все параметры действия кроме тех, которые были переданы как аргументы.
Также существует метод `Url::canonical()`, который позволяет создать [канонический URL](https://en.wikipedia.org/wiki/Canonical_link_element) (статья на англ., перевода пока нет) для текущего действия. Этот метод при создании игнорирует все параметры действия кроме тех, которые были переданы как аргументы.
Пример:
```php
......
docs/guide-ru/start-workflow.md
......@@ -34,7 +34,7 @@ basic/ корневой каталог приложения
commands/ содержит классы консольных команд
controllers/ контроллеры
models/ модели
runtime/ файлы, которые генерирует Yii во время выполнения приложения (логи, кеш и т.п.)
runtime/ файлы, которые генерирует Yii во время выполнения приложения (логи, кэш и т.п.)
vendor/ содержит пакеты Composer'а и, собственно, сам фреймворк Yii
views/ виды приложения
web/ корневая директория Web приложения. Содержит файлы, доступные через Web
......@@ -62,7 +62,7 @@ basic/ корневой каталог приложения
На диаграмме показано как приложение обрабатывает запрос.
![Жизненный цикл запроса](images/application-lifecycle.png)
![Жизненный цикл запроса](images/request-lifecycle.png)
1. Пользователь обращается к [точке входа](structure-entry-scripts.md) `web/index.php`.
2. Скрипт загружает конфигурацию [configuration](concept-configurations.md) и создает экземпляр [приложения](structure-applications.md) для дальнейшей обработки запроса.
......
docs/guide-ru/structure-application-components.md
......@@ -50,14 +50,14 @@
## Встроенные компоненты приложения <a name="core-application-components"></a>
В Yii есть несколько *встроенных* компонентов приложения, с фиксированными ID и конфигурациями по-умолчанию. Например,
В Yii есть несколько *встроенных* компонентов приложения, с фиксированными ID и конфигурациями по умолчанию. Например,
компонент [[yii\web\Application::request|request]] используется для сбора информации о запросе пользователя и разбора его в
определенный [маршрут](runtime-routing.md); компонент [[yii\base\Application::db|db]] представляет собой соединение с базой данных,
через которое вы можете выполнять запросы. Именно с помощью этих встроенных компонентов Yii приложения могут обработать
запрос пользователя.
Ниже представлен список встроенных компонентов приложения. Вы можете конфигурировать их также как и другие компоненты приложения.
Когда вы конфигурируете встроенный компонент приложения и не указываете класс этого компонента, то значение по-умолчанию будет использовано.
Когда вы конфигурируете встроенный компонент приложения и не указываете класс этого компонента, то значение по умолчанию будет использовано.
* [[yii\web\AssetManager|assetManager]]: используется для управления и опубликования ресурсов приложения.
Более детальная информация представлена в разделе [Ресурсы](output-assets.md);
......
docs/guide-ru/structure-controllers.md
......@@ -130,7 +130,7 @@ ID контроллеров также могут содержать префи
* Добавить в начало [[yii\base\Application::controllerNamespace|пространство имен контроллеров]].
Ниже приведены несколько примеров, с учетом того, что [[yii\base\Application::controllerNamespace|пространство имен контроллеров]]
имеет значение по-умолчанию равное `app\controllers`:
имеет значение по умолчанию равное `app\controllers`:
* `article` соответствует `app\controllers\ArticleController`;
* `post-comment` соответствует `app\controllers\PostCommentController`;
......@@ -172,14 +172,14 @@ ID контроллеров также могут содержать префи
]
```
### Контроллер по-умолчанию <a name="default-controller"></a>
### Контроллер по умолчанию <a name="default-controller"></a>
Каждое приложение имеет контроллер по-умолчанию, указанный через свойство [[yii\base\Application::defaultRoute]].
Каждое приложение имеет контроллер по умолчанию, указанный через свойство [[yii\base\Application::defaultRoute]].
Когда в запросе не указан [маршрут](#ids-routes), тогда будет использован маршрут указанный в данном свойстве.
Для [[yii\web\Application|Веб приложений]], это значение `'site'`, в то время как для [[yii\console\Application|консольных приложений]],
это `'help'`. Таким образом, если задан URL `http://hostname/index.php`, это означает, что контроллер `site` выполнит обработку запроса.
Вы можете изменить контроллер по-умолчанию следующим образом в [настройках приложения](structure-applications.md#application-configurations):
Вы можете изменить контроллер по умолчанию следующим образом в [настройках приложения](structure-applications.md#application-configurations):
```php
[
......@@ -375,10 +375,10 @@ public function actionView(array $id, $version = null)
о параметрах консольных приложений представлено в секции [Консольные команды](tutorial-console.md).
### Действие по-умолчанию <a name="default-action"></a>
### Действие по умолчанию <a name="default-action"></a>
Каждый контроллер имеет действие, указанное через свойство [[yii\base\Controller::defaultAction]].
Когда [маршрут](#ids-routes) содержит только ID контроллера, то подразумевается, что действие контроллера по-умолчанию
Когда [маршрут](#ids-routes) содержит только ID контроллера, то подразумевается, что действие контроллера по умолчанию
было запрошено.
По-умолчанию, это действие имеет значение `index`. Если вы хотите изменить это значение, просто переопределите данное
......@@ -409,7 +409,7 @@ class SiteController extends Controller
1. Метод [[yii\base\Controller::init()]] будет вызван после того как контроллер будет создан и сконфигурирован;
2. Контроллер создает объект действия, основываясь на запрошенном ID действия:
* Если ID действия не указан, то будет использовано [[yii\base\Controller::defaultAction|ID действия по-умолчанию]];
* Если ID действия не указан, то будет использовано [[yii\base\Controller::defaultAction|ID действия по умолчанию]];
* Если ID действия найдено в [[yii\base\Controller::actions()|карте действий]], то отдельное действие будет создано;
* Если ID действия соответствует методу действия, то встроенное действие будет создано;
* В противном случае, будет выброшено исключение [[yii\base\InvalidRouteException]].
......
docs/guide-ru/structure-views.md
......@@ -239,7 +239,7 @@ ID контроллера: <?= $this->context->id ?>
### Передача данных между видами <a name="sharing-data-among-views"></a>
[[yii\base\View|Компонент вида]] имеет свойство [[yii\base\View::params|params]] , которое вы можете использовать для обмена данными между видами.
[[yii\base\View|Компонент вида]] имеет свойство [[yii\base\View::params|params]], которое вы можете использовать для обмена данными между видами.
Например, в виде `about` вы можете указать текущий сегмент хлебных крошек с помощью следующего кода.
......@@ -298,7 +298,7 @@ use yii\helpers\Html;
Большинство шаблонов вызывают методы, аналогично тому, как это сделано в примере выше, чтобы скрипты и тэги, зарегистированные в других местах приложения могли быть правильно отображены в местах вызова (например, в шаблоне).
- [[yii\base\View::beginPage()|beginPage()]]: Этот метод нужно вызывать в самом начале шаблона.
Он вызывает событие [[yii\base\View::EVENT_BEGIN_PAGE|EVENT_BEGIN_PAGE]] , которое происходит при начале обработки страницы.
Он вызывает событие [[yii\base\View::EVENT_BEGIN_PAGE|EVENT_BEGIN_PAGE]], которое происходит при начале обработки страницы.
- [[yii\base\View::endPage()|endPage()]]: Этот метод нужно вызывать в конце страницы.
Он вызывает событие [[yii\base\View::EVENT_END_PAGE|EVENT_END_PAGE]] . Оно указывает на обработку конца страницы.
- [[yii\web\View::head()|head()]]: Этот метод нужно вызывать в `<head>` секции страницы html.
......@@ -320,7 +320,7 @@ use yii\helpers\Html;
### Использование шаблонов <a name="using-layouts"></a>
Как было описано в секции [Рендеринг в контроллерах](#rendering-in-controllers) , когда вы рендерите вид, вызывая метод [[yii\base\Controller::render()|render()]] из контроллера, к результату рендеринга будет применен шаблон. По умолчанию будет использован шаблон `@app/views/layouts/main.php` .
Как было описано в секции [Рендеринг в контроллерах](#rendering-in-controllers), когда вы рендерите вид, вызывая метод [[yii\base\Controller::render()|render()]] из контроллера, к результату рендеринга будет применен шаблон. По умолчанию будет использован шаблон `@app/views/layouts/main.php` .
Вы можете использовать разные шаблоны, конфигурируя [[yii\base\Application::layout]] или [[yii\base\Controller::layout]].
Первый переопределяет шаблон, который используется по умолчанию всеми контроллерами, а второй переопределяет шаблон в отдельном контроллере.
......@@ -391,7 +391,7 @@ Yii определяет какой шаблон использовать для
Например, вы определяете (записываете) блок в виде и отображаете его в шаблоне.
Для определения блока вызываются методы [[yii\base\View::beginBlock()|beginBlock()]] и [[yii\base\View::endBlock()|endBlock()]].
После определения, блок доступен через `$view->blocks[$blockID]` , где `$blockID` - это уникальный ID, который вы присваиваете блоку
После определения, блок доступен через `$view->blocks[$blockID]`, где `$blockID` - это уникальный ID, который вы присваиваете блоку
в начале определения.
В примере ниже показано, как можно использовать блоки, определенные в виде, чтобы динамически изменять фрагменты шаблона.
......
docs/guide-ru/structure-widgets.md
......@@ -108,7 +108,7 @@ class HelloWidget extends Widget
}
```
Для того, что бы использовать этот виджет, достаточно добавить в представление следующий код:
Для того, чтобы использовать этот виджет, достаточно добавить в представление следующий код:
```php
<?php
......@@ -177,7 +177,7 @@ public function run()
По умолчанию, файлы представлений виджетов должны находиться в директории `WidgetPath/views`, где `WidgetPath` -
директория, содержащая файл класса виджета. Таким образом, в приведенном выше примере, для виджета будет
использован файл представления `@app/components/views/hello.php`, при этом файл с классом виджета расположен в
`@app/components`. Для того, что бы изменить директорию, в которой содержатся файлы-представления для виджета,
`@app/components`. Для того, чтобы изменить директорию, в которой содержатся файлы-представления для виджета,
следует переопределить метод [[yii\base\Widget::getViewPath()]].
......
docs/guide-ru/tutorial-core-validators.md
......@@ -238,7 +238,7 @@ function foo($model, $attribute) {
строка, содержащая имена файловых расширений, разделенных пробелом или запятой (пр.: "gif, jpg").
Имя расширения не чувствительно к регистру. По умолчанию - null, что значит, что все имена файловых расширений
допустимы.
- `mimeTypes`: список MIME-типов которые допустимы для загрузки. Это может быть или массив, или строка,
- `mimeTypes`: список MIME-типов, которые допустимы для загрузки. Это может быть или массив, или строка,
содержащая MIME-типы файлов, разделенные пробелом или запятой (пример: "image/jpeg, image/png").
Имена mime-типов не чувствительны к регистру. По умолчанию - null, что значит, что допустимы все MIME-типы.
- `minSize`: минимальный размер файла в байтах, разрешенный для загрузки. По умолчанию - null, что значит, что нет
......
docs/guide-uk/concept-aliases.md 0 → 100644
Псевдоніми
=========
Псевдоніми використовуються для позначення шляхів до файлів або URL адрес і допомагають уникнути використання абсолютних шляхів
або URL в коді. Для того, щоб не переплутати псевдонім із звичайним шляхом до файлу або URL, він повинен починатися з `@`. В Yii
є безліч заздалегідь визначених псевдонімів. Наприклад, `@yii` вказує на директорію, в яку був встановлений
Yii framework, а `@web` можна використовувати для отримання базового URL поточного додатку.
Створення псевдонімів <a name="defining-aliases"></a>
----------------------------------------------
Для створення псевдоніма шляху до файлу або URL використовується метод [[Yii::setAlias()]]:
```php
// псевдонім шляху до файлу
Yii::setAlias('@foo', '/path/to/foo');
// псевдонім URL
Yii::setAlias('@bar', 'http://www.example.com');
```
> Примітка: псевдонім шляху до файлу або URL *не* обов'язково вказує на існуючий файл або ресурс.
Використовуючи вже заданий псевдонім, ви можете отримати на основі нього новий без виклику [[Yii :: setAlias ​​()]]. Зробити це можна, додавши в його кінець `/`, за яким слід один або більше сегментів шляху. Псевдоніми, визначені за допомогою
[[Yii::setAlias()]], є *кореневими псевдонімами*, в той час як отримані з них називаються похідними псевдонімами. На приклад, `@foo` є кореневим псевдонімом, а `@foo/bar/file.php` — похідним.
Ви можете задати новий псевдонім, використовуючи раніше створений псевдонім (не важливо, кореневої він чи похідний):
```php
Yii::setAlias('@foobar', '@foo/bar');
```
Кореневі псевдоніми, як правило, створюються на етапі [попереднього завантаження (bootstrapping)](runtime-bootstrapping.md).
Наприклад, ви можете викликати [[Yii::setAlias()]] у [вхідному скрипті](structure-entry-scripts.md). Для зручності, в
[додатку (Application)](structure-applications.md) передбачено властивість `aliases`, яке можна задати через
[конфігурацію додатку](concept-configurations.md):
```php
return [
// ...
'aliases' => [
'@foo' => '/path/to/foo',
'@bar' => 'http://www.example.com',
],
];
```
Перетворення псевдонімів <a name="resolving-aliases"></a>
----------------------------------------------------
Метод [[Yii :: getAlias ​​()]] перетворює кореневої псевдонім в шлях до файлу або URL, який цей псевдонім представляє. Цей же метод може працювати і з похідними псевдонімами:
```php
echo Yii::getAlias('@foo'); // виведе: /path/to/foo
echo Yii::getAlias('@bar'); // виведе: http://www.example.com
echo Yii::getAlias('@foo/bar/file.php'); // виведе: /path/to/foo/bar/file.php
```
Шлях або URL, представлений похідним псевдонімом, визначається шляхом заміни в ньому частині, що відповідає кореневого псевдоніму, на відповідний йому шлях або URL.
> Примітка: Метод [[Yii :: getAlias ​​()]] не перевіряє фактичного існування одержуваного шляху або URL.
Кореневої псевдонім може містити знаки '/'. При цьому метод [[Yii::getAlias()]] коректно визначить, яка частина псевдоніма є кореневої і вірно сформує шлях або URL:
```php
Yii::setAlias('@foo', '/path/to/foo');
Yii::setAlias('@foo/bar', '/path2/bar');
Yii::getAlias('@foo/test/file.php'); // виведе: /path/to/foo/test/file.php
Yii::getAlias('@foo/bar/file.php'); // виведе: /path2/bar/file.php
```
Якби `@foo/bar` не був оголошений кореневим псевдонімом, остання строка вивела б `/path/to/foo/bar/file.php`.
Використання псевдонімів. <a name="using-aliases"></a>
------------------------------------------------
Псевдоніми розпізнаються в багатьох частинах Yii без необхідності попередньо викликати [[Yii::getAlias()]] для отримання шляху або URL. Наприклад, [[yii\caching\FileCache::cachePath]] приймає як звичайний шлях до файлу, так і псевдонім шляху завдяки префіксу `@`, який дозволяє їх розрізняти.
```php
use yii\caching\FileCache;
$cache = new FileCache([
'cachePath' => '@runtime/cache',
]);
```
Для того, щоб дізнатися чи підтримує метод або властивість псевдоніми, зверніться до документації API.
Заздалегідь визначені псевдоніми <a name="predefined-aliases"></a>
----------------------------------------------------------
В Yii заздалегідь визначені псевдоніми для часто використовуваних шляхів до файлів і URL:
- `@yii`: директорія, в якій знаходиться файл `BaseYii.php` (директорія фреймворка).
- `@app`: [[yii\base\Application::basePath|базовий шлях]] поточного додатку.
- `@runtime`: [[yii\base\Application::runtimePath|директорія runtime]] поточного додатку.
- `@vendor`: [[yii\base\Application::vendorPath|директорія vendor Composer].
- `@webroot`: вебрут поточного веб додатка (там де `index.php`).
- `@web`: базовий URL поточного додатку.
Псевдонім `@yii` задається в момент підключення файлу `Yii.php` у [вхідному скрипті](structure-entry-scripts.md).
Решта псевдоніми задаються в конструкторі додатки в момент застосування [конфигурації](concept-configurations.md).
Псевдоніми розширень <a name="extension-aliases"></a>
------------------------------------------------
Для кожного [розширення](structure-extensions.md), встановлюваного через Composer, автоматично задається псевдонім.
Його ім'я відповідає кореневого простору імен розширення відповідно до його `composer.json`. Псевдонім представляє
шлях до кореневої директорії пакета. Наприклад, якщо ви встановите розширення `yiisoft/yii2-jui`, то вам автоматично стане доступний псевдонім `@yii/jui`. Він створюється на етапі [первинного завантаження (bootstrapping)](runtime-bootstrapping.md)
приблизно так:
```php
Yii::setAlias('@yii/jui', 'VendorPath/yiisoft/yii2-jui');
```
docs/guide-uk/concept-autoloading.md
......@@ -4,12 +4,12 @@
[автозавантаження класів](http://www.php.net/manual/ru/language.oop5.autoload.php). Фреймворк надає свій швидкий сумісний з [PSR-4](https://github.com/php-fig/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader.md)
автозавантажувач, який встановлюється в момент підключення `Yii.php`.
> Примітка: Для простоти оповіді, в цьому розділі ми будемо говорити тільки про автозавантаження класів. Тим не менш, все описане застосовно до інтерфейсів і трейтам.
> Примітка: Для простоти оповіді, в цьому розділі ми будемо говорити тільки про автозавантаження класів. Тим не менш, все описане може бути застосовно до інтерфейсів і трейтів.
Як використовувати автозавантажувач Yii <a name="using-yii-autoloader"></a>
--------------------------------------------------------------
При використанні автозавантажувач класів Yii слід дотримуватися два простих правила створення і іменування класів:
При використанні автозавантажувача класів Yii слід дотримуватися два простих правила створення і іменування класів:
* Кожен клас повинен належати простору імен (тобто `foo\bar\MyClass`).
* Кожен клас повинен знаходитися в окремому файлі, шлях до якого визначаться наступним правилом:
......@@ -65,13 +65,13 @@ require(__DIR__ . '/../vendor/autoload.php');
require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
```
Ви можете використовувати автозавантажувач Composer без автозавантажувач Yii. Однак, швидкість автозавантаження в цьому випадку може зменшиться. Також вам буде необхідно слідувати правилам автозавантажувача Composer.
Ви можете використовувати автозавантажувач Composer без автозавантажувачa Yii. Однак, швидкість автозавантаження в цьому випадку може зменшиться. Також вам буде необхідно слідувати правилам автозавантажувача Composer.
> Інформація: Якщо ви не хочете використовувати автозавантажувач Yii, створіть свою версію файлу `Yii.php`
і підключіть його в [вхідному скрипті](structure-entry-scripts.md).
Автозагрузка класів розширень <a name="autoloading-extension-classes"></a>
Автозавантаження класів розширень <a name="autoloading-extension-classes"></a>
-------------------------------------------------------------------
Автозавантажувач Yii може автоматично завантажувати класи [розширень](structure-extensions.md) в тому випадку, якщо дотримується єдине правило. Розширення повинно правильно описати розділ 'autoload' у файлі 'composer.json'. Більш докладно про це можна дізнатися з [офіційній документації Composer](https://getcomposer.org/doc/04-schema.md#autoload).
......
docs/guide-uk/start-workflow.md
......@@ -62,7 +62,7 @@ basic/ кореневий каталог додатка
На діаграмі показано як додаток опрацьовує запит.
![Життєвий цикл запиту](../guide/images/application-lifecycle.png)
![Життєвий цикл запиту](../guide/images/request-lifecycle.png)
1. Користувач звертається до [місця входження](structure-entry-scripts.md) `web/index.php`.
2. Скрипт завантажує конфігурацію [configuration](concept-configurations.md) і створює екземпляр [додатку](structure-applications.md) для наступного опрацювання запиту.
......
docs/guide-uk/structure-application-components.md 0 → 100644
Компоненти додатка
=====================
Додатки є [сервіс локаторами](concept-service-locators.md). Вони зберігають багато так званих
*компонентів додатку*, які надають різноманітні інструменти для опрацювання запитів. Наприклад,
компоненти `urlManager` відповідає за маршрутизацію веб запитів до потрібного контролера; компонент `db` надає інструменти для работи з базою даних; і т. д.
Кожний компонент додатка має свій унікальний ID, який дозволяє ідентифікувати його серед інших різноманітних компонентів
в одному і тому ж додатку. Ви можете отримати доступ до компонента наступним чином:
```php
\Yii::$app->ComponentID
```
Наприклад, ви можете використовувати `\Yii::$app->db` для отримання [[yii\db\Connection|з’єднання з БД]],
і `\Yii::$app->cache` для отримання доступу до основного компонента [[yii\caching\Cache|кеша]], зареєстрованого в додатку.
Компонентами додатку можуть бути любі об’єкти. Ви можете зареєструвати їх з допомогою властивості [[yii\base\Application::components]] в [конфігурації](structure-applications.md#application-configurations) додатка.
Наприклад,
```php
[
'components' => [
// реєстрація "cache" компонента з допомогою назви класу
'cache' => 'yii\caching\ApcCache',
// реєстрація "db" компонента з допомогою масива конфігурації
'db' => [
'class' => 'yii\db\Connection',
'dsn' => 'mysql:host=localhost;dbname=demo',
'username' => 'root',
'password' => '',
],
// реєстрація "search" компонента з допомогою анонімної функції
'search' => function () {
return new app\components\SolrService;
},
],
]
```
> Інформація: Хоча ви можете зареєструвати стільки компонентів в додатку скільки вам потрібно,
все ж таки варто робити це осмислено. Компоненти додатку схожі на глобальні змінні. Використання дуже великої кількості компонетів додатку може потенційно зробити ваш код складним для розробки і тестування.
В більшості випадків ви можете просто створити локальний компонент і використовувати його при необхідності.
## Вбудовані компоненти додатку <a name="core-application-components"></a>
В Yii є декілька *вбудованих* компонентів додатку, з фіксованими ID і конфігураціями за замовчуванням. Наприклад,
компонент [[yii\web\Application::request|request]] використовується для отримання інформації про запит користувача і розбору його в
певний [маршрут](runtime-routing.md); компонент [[yii\base\Application::db|db]] являє собою з’єднання з базою даних,
через яке ви можете виконувати запити. Саме з допомогою цих вбудованих компонентів Yii додатки можуть обрабляти
запит користувача.
Нижче наведений перелік вбудованих компонентів додатку. Ви можете конфігурувати їх так само як і інші компоненти додатку.
Коли ви конфігуруєте вбудований компонент додатку і не вказуєте клас цього компонента, то буде використовуватись значення за замовчуванням.
* [[yii\web\AssetManager|assetManager]]: використовується для керування і відображенням ресурсів додатку.
Більш детальна інформація представлена ​​в розділі [Ресурси](output-assets.md);
* [[yii\db\Connection|db]]: являє собою з’єднання з базою даних, через яке ви можете виконувати запити.
Зверніть увагу, що коли конфігуруєте даний компонент, ви маєте вказати клас компонента так як і решту необхідних параметрів, а саме такі як [[yii\db\Connection::dsn]].
Більш детальна інформація представлена ​​в розділі [Об’єкти доступу до даних (DAO)](db-dao.md);
* [[yii\base\Application::errorHandler|errorHandler]]: здійснює опрацювання PHP помилок і виключень.
Більш детальна інформація представлена ​​в розділі [Обробка помилок](runtime-handling-errors.md);
* [[yii\base\Formatter|formatter]]: форматує дані для відображення їх кінцевому користувачу. Наприклад, число може
бути зображене з різноманітними розділителями, дата може бути зображена в форматі `long`.
Більш детальна інформація представлена ​​в розділі [Форматування даних](output-formatting.md);
* [[yii\i18n\I18N|i18n]]: використовується для перекладу повідомлень і форматування.
Більш детальна інформація представлена ​​в розділі [Інтернаціоналізація](tutorial-i18n.md);
* [[yii\log\Dispatcher|log]]: обробка і маршрутизація логів.
Більш детальна інформація представлена ​​в розділі [Логування](runtime-logging.md);
* [[yii\swiftmailer\Mailer|mail]]: надає можливості для побудови і розсилки поштових повідомлень.
Більш детальна інформація представлена ​​в розділі [Відправлення пошти](tutorial-mailing.md);
* [[yii\base\Application::response|response]]: являє собою дані від серверу, які будуть направлені користувачу.
Більш детальна інформація представлена ​​в розділі [Відповіді](runtime-responses.md);
* [[yii\base\Application::request|request]]: являє собою запит, отриманий від кінцевого користувача.
Більш детальна інформація представлена ​​в розділі [Запити](runtime-requests.md);
* [[yii\web\Session|session]]: інформація про сесії. Даний компонент доступний тільки в [[yii\web\Application|веб додатках]].
Більш детальна інформація представлена ​​в розділі [Сесії і куки](runtime-sessions-cookies.md);
* [[yii\web\UrlManager|urlManager]]: використовується для розбору і побудови URL.
Більш детальна інформація представлена ​​в розділі [Розбір і генерація URL](runtime-url-handling.md);
* [[yii\web\User|user]]: являє собою інформацію авторизованого користувача.
Даний компонент доступний тільки в [[yii\web\Application|веб додатках]].
Більш детальна інформація представлена ​​в розділі [Аутентифікація](security-authentication.md);
* [[yii\web\View|view]]: використовується для відображення представлень.
Більш детальна інформація представлена ​​в розділі [Представлення](structure-views.md).
docs/guide-zh-CN/README.md
......@@ -62,7 +62,7 @@ Yii 2.0 权威指南
* **已定稿** [行为（Behavior）](concept-behaviors.md)
* **已定稿** [配置（Configurations）](concept-configurations.md)
* **已定稿** [类自动加载（Autoloading）](concept-autoloading.md)
* **已定稿** [别名（Alias）](concept-alias.md)
* **已定稿** [别名（Alias）](concept-aliases.md)
* **已定稿** [服务定位器（Service Locator）](concept-service-locator.md)
* **已定稿** [依赖注入容器（DI Container）](concept-di-container.md)
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment