Download the PHP package h4d/leveret without Composer

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

FAQ

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

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

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

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

Informations about the package leveret

¿Qué es Leveret?

Es un microframework que permite crear aplicaciones HTTP de forma sencilla (al estilo de slim, silex, etc).

¿Cómo se instala?

Para instalar leveret vía composer debes ejecutar:

NOTA: Es necesario incluir todos los datos de los repositorios de las dependecias que están alojadas en repositorios privados. Por ejemplo, como h4d/leveret depende del paquete h4d/template es necesario incluir también los datos de ese repositorio (composer no lo "resuelve" de forma automática como en el caso de los paquetes publicados en packagist).

¿Cómo se utiliza?

Fichero de configuración

Para que funcione la aplicación es necesario crear un fichero de configuración cuya ruta se pasará como parámetro al constructor de \H4D\Leveret\Application. Si no se pasa un fichero de configuración al constructor se instanciará una aplicación con valores de configuración por defecto.

En el siguiente cuadro se muestra el contenido del fichero de configuración por defecto.

NOTA: Si las rutas indicadas en el fichero de configuración son relativas iran referidas al directorio raiz del servidor.

Instanciación de un aplicación

Registro de rutas

Las rutas se registran mediante el método registerRoute($method, $routePattern).

El primer parámetro indicará el método HTTP (GET, POST, DELETE, etc). El segundo parámetro es una representación de la ruta a la que se debe atender.

Las representaciones de las rutas soportan "cadenas comodín". El formato válido de las cadenas comodín es el siguiente: :(tipo)nombre, en donde tipo es el tipo de la variable (int, float, string, etc) y nombre es el nombre/alias de la variable. La parte de la "cadena comodín" que especifica el tipo es opcional y se asume que si no se especifica el tipo la variable será de tipo string.

Los tipos soportados hasta el momento por las cadenas comodín son:

Ejemplos de "cadenas comodín":

Ejemplo de reprentaciones de rutas:

A cada ruta se le debe asignar una acción mediante el método setAction($clousure), del siguiente modo:

En el caso de querer pasar otras variables a la clousue, o incluso la aplicación completa, lo podemos hacer mediante el uso de use:

Un modo alternativo de asignar acciones a las rutas es mediante el uso de controllers. Se puede establecer la dupla controller/acción vía método useController($controllerClassName, $controllerClassMethod), en donde el primer parámetro es el nombre de la clase del controller y el segundo es el nombre del método que queremos que sea ejecutado durante el dispatch.

Esto es un ejemplo de asignación de una dupla controller/acción a una ruta.

Para cada ruta se pueden asociar múltiples acciones de predispatch y post dispatch de forma opcional. Para esto se dispone de los métodos addPreDispatchAction($callable) y addPostDispatchAction($callable). A los "callable" se le pasan por defecto como parámetros la ruta a la que están asociados y la aplicación, de este modo tendrán acceso a cualquier subcomponente de la aplicación (logger, request, response, etc).

En el siguiente ejemplo se añade una acción de predispatch que modifica los parámetros de la petición, poniendo en mayúsculas todos los parámetros de tipo string.

Registro de rutas en el fichero de configuración

Pueden registrarse rutas sencillas desde el fichero de configuración de la aplicación.

Para activar el registro de rutas definidas en el fichero de configuración es necesario que el valor de configuración registerRoutesDefinedInConfigFile esté definido a true

Las rutas se configuran en la sección [routes] y pueden ser de dos tipos:

Definición de ruta que apunta a un Controller/Action:

Definición de ruta que apunta a un método de la clase de la aplicación:

Validación de las peticiones

Cuando se registra una ruta en la aplicación se pueden añadir los validadores necesarios para cada uno de los parámetros que se espera recibir. El método disponible para tal efecto es addRequestConstraints($paramName, [Constraints]), que acepta como primer parámetro un string que identifica el nombre del parámetro a validar y como segundo parámetro una regla (Constraint) o conjunto de reglas (array de Constraints) que el parámetro debe cumplir.

En el siguiente ejemplo de añaden varias reglas de validación a los parámetros username y alias.

Las reglas de validación deben ser instancias de clases que cumplan con la interfaz H4D\Leveret\Validation\ConstraintInterface. En el caso de necesitar reglas de validación que no cumplan con esa interfaz siempre se puede hacer un adaptador, como por ejemplo H4D\Leveret\Validation\Adapters\H4DConstraintAdapter que permite utilizar las reglas de validación definidas en el proyecto h4d/validator o H4D\Leveret\Validation\Adapters\SymfonyConstraintAdapter que permite utilizar las reglas de validación del proyecto Symfony .

En el siguiente ejemplo se muestra el uso de una regla de validación de H4D mediante el uso del adaptador creado para tal efecto:

En el siguiente ejemplo se muestra el uso de reglas de validación de Symfony:

Desde el objeto Application de Leveret se puede obtener información de los resultados de la validación de una petición mediante los siguientes métodos:

Para más información sobre estos métodos ver la firma de los mismos.

Parámetros requeridos

Para definir qué parámetros de una ruta determinada son requeridos se dispone de dos métodos:

Ejemplo de uso:

Autovalidación de peticiones

Leveret permite configurar si se harán las validaciones de parámetros de modo automático (post rutinas de enrutado) o en modo manual. En el modo automático se puede definir el momento en el que se realizará la validación de la petición, si después de la autenticación (si es necesaria) o antes de la autenticación (si es necesaria).

Los tres modos se pueden configurar mediante el método setAutoRequestValidationMode($mode). Los valores posibles para el $mode son:

Para cada uno de los modos existen constantes definidas en la clase Application.

Ejemplo de uso:

Filtrado de parámetros POST|PUT|PATH|DELETE, parámetros de query y URL

Por defecto se aplica un filtro a todos los parámetros que llegan a la aplicación, ya sean por POST, PUT, PATH, DELETE, parámetros de query o URL. El filtro que se aplica por defecto se puede espeficicar en el fichero de config de la aplicación en el campo defaultInputFilterType. El valor de ese campo es un número entero equivalente a alguno de los filtros estandar de PHP ([ver documetación de PHP] (http://php.net/manual/en/filter.filters.sanitize.php)). Los valores más comunes para defaultInputFilterType se muestran a continuación:

Es posbile aplicar filtros específicos a los parámetros emplemando el método addRequestFilters($paramName, $filters), en donde $paramName es el nombre del parámetro que se quiere filtrar y $filters es un array de objetos que deben cumplir con la interfaz H4D\Leveret\Filter\FilterInterface (o closures que aceptan como parámetro un valor y devuelvan el valor filtrado).

Ejemplo:

Ejecución de la aplicación

El método run() es el que se encarga de enrutar las peticiones y proporcionar una respuesta HTTP al cliente.

Controllers

Los controllers de la aplicación deben heredar de H4D\Leveret\Application\Controller para poder ser empleados.

Desde cualquier método de un controller se puede acceder a la aplicación mediante la variable interna $app, y desde ese objeto acceder a la request, response, view, etc.

Ejemplo de un controller básico:

Método init()

En los controllers podemos implementar el método init() que se llamará cada vez que se instancie el controller que lo implemente.

Métodos preDispatch() y postDispatch()

En los controller podemos implementar los métodos preDispatch() y postDispatch() que tienen un comportamiento especial.

Otros métodos interesantes

Los controllers disponen de varios métodos de utilidad que pueden ser interantes, algunos de ellos son:

Vistas

Cuando necesitemos utilizar una plantilla podremos hacer uso de la vista por defecto asociada a la aplicación para pasar las variables que serán sustituidas en la plantilla mediante los métodos correspondientes (ver H4D\Leveret\Application\View.php).

Para especificar la plantilla que queremos renderizar se empleará el método render($template) del objeto aplicación. El único parámetro que admite es la ruta relativa del fichero de la plantilla con respecto a la ruta base de las vistas (definida en el fichero de configuración de la aplicación en la sección views/path)

Las plantillas serán normalmente ficheros phtml (aunque podrían ser cualquier otra cosa).

Ejemplo de una plantilla:

Vistas parciales

Se pueden emplear vistas parciales dentro de otras vistas del siguiente modo:

Las vistas parciales "heredan" todos los métodos y variables de las vistas contenedoras.

Está permitido el uso de vistas parciales en el interior de vistas parciales. Por ejemplo:

En la vista principal:

En APP_VIEWS_DIR.'/partials/test/partial.phtml':

En APP_VIEWS_DIR.'/partials/test/internal.phtml'

¿Cómo se resuelven los nombres de variables dentro de los partials?

  1. Si la variable está definida en el partial se usa esa variable.
  2. Si la variable no está definida en el partial y sí en su vista contenedora se utiza la variable de la vista contenedora.
  3. Si la variable no está definida en el partial y tampoco en la vista contenedora, se lanza una excepción de renderizado.

OJO! Un partial interno no "hereda" las variables del partial contedor, sólo las de la vista contenedora.

Layouts

Los layouts son vistas que se pueden emplear como un contenedor de otras vistas. En todo layout existirá una variable por defecto con nombre $contents que será sustituida por el contenido de otra vista en las rutina de renderizado de la aplicación.

Para hacer uso de un layout determinado se debe emplear el método de la aplicación useLayout($template), en donde $template es la ruta relativa del fichero de la plantilla del layout con respecto a la ruta base de las vistas de la aplicación.

Eventos

Tanto la aplicación como los controllers de Leveret implementan el patrón publisher, por lo que pueden publicar eventos mediante el método publish(Event $event).

A los eventos de la aplicación pueden subscribirse tantos listereners/observers/subscribers como sea necesario, para ello se utiliza el método attachSubscriber(SubscriberInterface $subscriber).

Si se quiere retirar un listener se usaría el método dettachSubscriber(SubscriberInterface $subscriber).

Los controllers disponen de los mismos métodos para agregar o retirar listeners. Todos los eventos que se publiquen desde un controller se propagan a la aplicación.

Inyector de dependencias / contenedor de servicios

Leveret incluye un contenedor de servicios muy simple que soporta los siguientes tipos:

Para registrar un servicio en la aplicación puede usarse el el método registerService( string $serviceName, mixed $value, $singleton = false) del objeto aplicación. En donde:

Para recuperar los servicios registrados el objeto aplicación dispone del método getService( string $serviceName) en donde:

Otros métodos útiles en relación con los servicios son:

Las aplicaciones de Leveret tienen un lugar destinado para el registro de servicios, ese lugar es el método initServices() de la clase de nuestra aplicación.

Registro de instancias como servicios

Ejemplo: Registro de una instancia de la clase MyService como un servicio de la aplicación.

Registro de callables como servicios

Ejemplo: Registro del servicio 'ServiceName'. Al asignar el valor true al tercer parámetro ($singleton) la primera vez que llame a $app->getService('ServiceName') se creará una instancia de MyService y se devoverá. En llamadas posteriores se devolverá la misma instancia de MyService, no se volverá a ejecutar el código del callable.

Si quisiesemos que se creasen diferentes instancias de MyService cada vez que llamemos a $app->getService('ServiceName') bastaría con cambiar el valor del parámetro $singleton a false.

Ejemplo: Registro del servicio 'ServiceName'. Cada vez que se llama a $app->getService('ServiceName') se instancia un nuevo objeto de la clase MyService y se devuelve.

NOTA: El registro de callables tiene una ventaja importante sobre el registro de instancias: el código de instanciación de objetos no se ejecuta si no se llama a $app->getService('ServiceName'), por lo tanto, registrar los servicios como callables puede representar un menor tiempo de "bootstraping" de la aplicación y un menor consumo de memoria, dado que sólo se crearán nuevas instancias cuando se haga uso de los servicios, y además la instanción se relalizará en tiempo de ejecución y no en el tiempo de carga de la aplicación.

Registro pares clave-valor como servicios

Leveret permite el registro de pares clave-valor como servicios del siguiente modo:

Registro de recursos como servicios

Al igual que en el resto de casos, para registrar un recurso (resource) como un servicio en nuestra aplicación, haremos uso del método $app->registerService( string $serviceName, resource $resuorce)

ACLs

Leveret soporta el uso de ACL (access control lists) básicas. Con ellas podemos limitar el acceso a determinados componentes de nuestas aplicación en base a unas reglas que nosotros podemos definir (que deben cumplir con la interfaz H4D\Leveret\Application\AclInterface).

El lugar destinado para el registro de ACLs es el método initAcls() de la clase de nuestra aplicación.

Es posible registras ACLs para rutas y para controllers/actions, para ello se disponen los métodos:

Registro de ACLs para rutas

Para registrar una o varias ACLs para una ruta determanada debemos emplear el método de la aplicación: registerAclForRoute(AclInterface $acl, string $routeName), en donde:

Registro de ACLs para controllers

Podemos registrar ACLs que se apliquen sobre un controller o determinados action de un controller empleando el siguiente método de nuestra aplicación: *registerAclForController(AclInterface $acl, string $controllerName, array $applyToActions = [''], array $excludedActions = [])**, en donde:

Ejemplo: Aplicación de la ACL AdminLoggedInRequired (registrada como servicio) sobre el controller MyAppp\Controller\AdminController

Ejemplo completo:


All versions of leveret with dependencies

PHP Build Version
Package Version
Requires php Version >=5.5.9
psr/log Version ~1.0
h4d/template Version ^1.0
h4d/i18n Version ^1.0.4
h4d/patterns Version ^1.0.7
retrinko/ini Version ^1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package h4d/leveret contains the following files

Loading the files please wait ....