Hoy traigo un pequeño HOWTO con una joya de Symfony. Se trata de un bundle, plugin o módulo (como prefieras llamarlo) para Symfony. Es una plataforma completa en origen, pero podemos sólo usar el núcleo de dicha plataforma en nuestro proyecto. Así en menos de 1 hora tendremos montada nuestra API en nuestro proyecto. Es decir, integrando el núcleo de este bundle en nuestro proyecto, se generarán automáticamente todas las funcionalidades clásicas de una API REST de todo lo que tengamos en nuestro proyecto.
Para los no duchos en el tema, una API es un punto de entrada a nuestro proyecto. Por ejemplo, si tenemos animales en nuestro proyecto, y dejamos en la API la gestión de estos animales, podremos listarlos, editarlos, crearlos o borrarlos.. Todo remotamente desde la API, desde una aplicación móvil, desde otra web, alimentando otros sistemas informáticos con esta información, cualquier cosa que se nos ocurra se puede hacer con una API.
Es decir, por excelencia las APIs son la mejor forma de interconectar sistemas informáticos. Y no es que ahora se hayan puesto de moda, sino que en el año 2000 se pusieron de moda. Y con Symfony mediante este proyecto se simplifica mucho su puesta en marcha.
Cuando has valorado bien un proyecto, y es tal el nivel de personalización que se quiere alcanzar, no queda más remedio que hacer un desarrollo artesanal, o a la larga te arrepentirás. Ya que partir de un CMS prefabricado es, a veces, más que una ayuda un lastre. Cuando quieres la máxima flexibilidad, velocidad en las modificaciones.. y por supuesto, la máxima calidad.. tienes que ir al desarrollo sobre frameworks. Ya hablé sobre esto en otro post anterior..
Hoy vengo a empezar con una serie de plugins o bundles para Symfony, hoy con uno para programar tareas. Ya sea para enviar emails transaccionales, para programar tareas de marketing, crawleos de sitios web, generar sitemaps, o lo que sea que quieras automatizar.. Aquí verás como en un rato tienes montado un estupendo programador de tareas.
Con este programador de tareas ya tienes el panel de control hecho. Es decir, te evitas la construcción del panel, y podrás ir al siguiente paso en menos de una hora. Que será directamente el ir a crear las tareas tal y como las necesites para tu proyecto 🙂
Es el gran dilema en el desarrollo de aplicaciones web. Te hablan sobre un proyecto; con unos requerimientos, unas especificaciones. Debes elegir con las premisas que te dan: presupuesto, tiempo de entrega, calidad, flexibilidad, mantenibilidad, practicidad.. ¿Existe ya una solución para el proyecto? ¿Se puede partir de un CMS y modificarlo? ¿Son demasiadas las modificaciones que se van a hacer al CMS? ¿Es viable partir de un framework de calidad? ¿Buscamos máxima calidad, o menor precio? ¿Hay muchos desarrolladores disponibles en el mercado para mantener el proyecto?
El 7 de noviembre de 2016 se publicó la nueva versión 1.7 de Prestashop. Esta versión trae un remake del 100% del core, reescrito con Symfony. Cuando leí sobre esto, empezó a intrigarme más y más. Quería ver cómo iba este proyecto. Pasó por mis manos un proyecto que funciona en Prestashop 1.6, ¡qué lástima!, no íbamos a actualizarlo. Pero ahora sí, tenemos entre manos un nuevo proyecto, y tenemos que estimar a ver si lo montamos sobre Prestashop 1.7. Así que manos a la obra..
Las nubes por definición son sistemas informáticos que crecen o decrecen según la necesidad. Son conjuntos de servidores/servicios que se adaptan a la demanda. Con todo esto, llegamos a una de las cosas más interesantes de AWS, el auto-escalado o la tolerancia a fallos, además de la personalización de los servidores. Podemos controlar la carga de los servidores que haya. Además automatizar el arranque y parada a ciertas horas de algunos de los servidores. O podemos duplicar los sistemas para evitar los ‘single point of failure como una casa’.
En OpsWorks tenemos herramientas muy interesantes relacionadas con esto. Algo rústicas, quizá clásicas dirían algunos. Pero gracias a ello, sin límites en la flexibilidad para configurar. Y si lo llevamos al extremo, este mismo sistema nos puede servir para automatizar la creación de nuestros servidores con herramientas como Chef y Kitchen. Todo esto y mucho más es lo que se puede hacer con el clásico OpsWorks.
Primero tendremos que ver qué son las AMIs. Cómo crear una manualmente o automáticamente. Y finalmente veremos cómo se usan, para hacernos una buena idea de qué podemos hacer en OpsWorks, y si es o no lo que necesitamos. Quizá es interesante ir a Docker con el EC2 Container Service o a CloudFormation, pero esto son otros temas..
No voy a entrar al detalle de cómo hacer cada cosa, no terminaría nunca. Así que si buscas una guía general para enfrentar después cada detalle poco a poco, este es tu post.
Este estupendo CMS orientado a la venta online de productos hace las delicias de los vendedores, de igual modo de los maquetadores, y cómo no, también de los programadores.
Como analista programador llevaba ya un tiempo queriendo meterle mano a las entrañas de Magento. Así que poco a poco, he ido cogiendo los manuales para el usuario, luego el del diseñador, y ahora tengo entre manos el del programador. Ahora según van surgiendo las necesidades voy haciendo incursiones cada vez más a fondo en el código fuente de esta humongous web application.
La verdad es que lo estoy disfrutando porque Magento está desarrollado con una buena estructura y sobre un gran framework de desarrollo PHP, el Zend Framework. Incorporando técnicas de programación que le dan una gran flexibilidad sin añadir demasiada complejidad.
Este es un pequeño HOWTO para tener de referencia.
Si tienes una relación entre dos entidades de la forma ManyToMany, una de ellas tendrá inversedBy y la otra mappedBy. Con un ejemplo se ve más claro.
Suponiendo que has generado las acciones CRUD con el comando siguiente:
$ php app/console doctrine:generate:crud
Supongamos que tenemos usuarios y negocios relacionados así, en una relación muchos a muchos. En la entidad Business tenemos: /** * @ORMManyToMany(targetEntity=»User», * inversedBy=»users», cascade={«persist»}) */ private $users;
Y en la entidad User tenemos:
/** * @ORMManyToMany(targetEntity=»Business», * mappedBy=»users», cascade={«persist»}) * @ORMJoinColumn(onDelete=»SET NULL») */ private $businesses; Ahora el editar los usuarios tenemos en el formulariode edición de un usuario lo siguiente:
->add(‘businesses’, ‘entity’, array( ‘by_reference’ => false, //.. )) La entidad inversedBy, que en este caso es Business, guardará correctamente los Users referenciados al editarlos. Pero al contrario con la entidad Users, tiene los Business mapeados, lo que hará que no guarde automáticamente las referencias.
Hay que añadir lo que he puesto en negrita en los códigos anteriores y en la entidad User lo siguiente para permitir que añada y borre los Business correctamente.
/** * Add businesses. * * @param AppBundleEntityBusiness $businesses * * @return User */ public function addBusiness(AppBundleEntityBusiness $business) { $this->businesses[] = $business; $business->addUser($this);
return $this; }
/** * Remove businesses. * * @param AppBundleEntityBusiness $businesses */ public function removeBusiness(AppBundleEntityBusiness $business) { $this->businesses->removeElement($business); $business->removeUser($this); }
Con ésto ya debe de funcionar. Si estamos editando un Business y añadimos o borramos Users lo hará correctamente, y de la forma inversa, si estamos editando un User, también añadirá o borrará Business.
Brutal el proyecto que están desarrollando en Sylius. Navegando y navegando por proyectos para hacer tiendas online. Viendo las principales opciones del mercado: Magento, Prestashop y WordPress con WooCommerce. Me planteaba la opción de cómo sería desarrollar una tienda completa en Symfony. Integrar pasarelas de pago, métodos de envío, ordenando todo los productos por categorías, valores, atributos de los productos.. es un trabajazo. Pero por otro lado no quería prescindir de la flexibilidad y agilidad que nos da un buen framework PHP, en este caso el gran Symfony.
Aterrizaje
Todas estas búsquedas me llevaron a encontrar Sylius. Lo que hasta ahora es el proyecto de tienda online basado en Symfony que me ha parecido más interesante. A fecha en que escribo está en fase de desarrollo aunque hay quien ya lo está utilizando.
Se trata de un proyecto Open Source, licenciado bajo la MIT license. Esto nos permite usar Sylius para cualquier proyecto, libremente sin coste de compra ninguno. Lo único que no se pude hacer es decir que Sylius lo hemos hecho nosotros, como es lógico. Se puede adaptar, modificar, ampliar, etc.. Cualquier cosa se puede hacer porque lo que tenemos entre manos es un proyecto Symfony.
Diferenciación
La principal diferenciación es que para modificarlo no tienes que leerte una ingente cantidad de documentación. Cuando estás desarrollando algo para algún CMS como WordPress, Magento, Joomla.. debes tener siempre a mano su documentación. Acabas especializándote y luego no te puedes salir de dicha plataforma. Por otro lado, el que mucho abarca poco aprieta, no te puedes espcializar mucho en un CMS en concreto. Si lo haces, que luego no te saquen de ahí porque cuando te llevan a otro CMS es otro mundo.
Al ser una plataforma 100% en Symfony, todo sigue el esquema general. Las plantillas están donde deben de estar, igual los controladores, las entidades de las bases de datos. La estructura de directorios es la misma que la de cualquier proyecto Symfony. Las nuevas librerías se añaden igual que cualquier proyecto Symfony. Todo está en su sitio. Esto agiliza mucho la adaptación y ampliación de funcionalidades. No necesitas sumergirte en un mar de documentación específica del CMS en cuestión.
Características
Por su propia naturaleza, se trata de un programa muy potente, rápido, flexible, adaptable y escalable a más no poder. Es como si se tratara de un desarrollo de una tienda 100% artesanal, pero donde estará casi todo listo para usar.
Esta siendo traducido a varios idiomas, con zona frontal, zona de administración. Tendremos productos, el clásico carro de la compra, productos organizados por categorías y atributos, formas de pago, métodos de envío, gestión de mensajes de clientes, páginas estáticas, además de muchas otras configuraciones. Incluso se prevee la inclusión de una API para interconectar el sistema Sylius con otros sistemas.
Resumiendo
¡Toda una joya de la informática! A mi me parece un gran proyecto. Que está siendo organizado empresarialmente desde Lakion.com. Una empresa que preveo que ofrecerá todo tipo de servicios alrededor del proyecto. De igual forma que hacen la mayoría de proyectos Open Source.
Resumiendo, tenemos un gran proyecto. Pretende revolucionar el mundo de los CMS de tiendas online. Está siendo una revolución en el mundo de la programación a medida. Y seguro que lo va a ser también en el mundo de los CMSs cuando alcance su madurez para que cualquier no-programador lo use.
Puede ser algo trivial, pero es el punto de partida para iniciar la internacionalización de una web. Me refiero a la llegada del usuario, recogida del código de idioma y región del navegador, se comprueban los idiomas disponibles y posteriormente se le redirige a la página de su idioma correspondiente.
Es mucho más sencillo que lo que puede parecer a priori, pero claro está, hay que tener claras un par de cosas que si no después se complica.
El usuario llega a la web
En este punto, tenemos un usuario que llega a la web. Ahora es el momento de elegir el idioma en que le vamos a mostrar la página web al usuario. Que podemos hacerlo de dos formas diferentes: eligiendo el idioma por defecto o con el idioma que nos sugiera el navegador.
Vamos a empezar con un ejemplo de controlador que recibe la visita inicial del usuario:
<?php namespace FrontBundleController;
use SymfonyBundleFrameworkBundleControllerController; use SensioBundleFrameworkExtraBundleConfigurationRoute; use SensioBundleFrameworkExtraBundleConfigurationTemplate; use SymfonyComponentHttpFoundationRequest; /* * Controlador de ejemplo para empezar a traducir una web. * Sólo tiene las dos rutas necesarias para empezar la navegación traducida * Se necesita de la entidad Idioma para tener los idiomas disponibles. */ class DefaultController extends Controller { /** * Esta ruta es la página de inicio. Simplemente recibe al visitante * busca entre los idiomas publicados y le redirige a la ruta siguiente * poniendo el código del idioma en la URL. * * @Route («/», name=»iniciototal») */ public function inicioTotalAction(Request $request) { $manager = $this->getDoctrine()->getManager();
// Creamos el array de idiomas disponibles que se obtienen de la // entidad Backbundle:Idioma, aquí lo que hacemos es recuperar de la // BD los idiomas publicados guardando en un array los códigos de idioma. $idiomas = $manager->getRepository(‘BackBundle:Idioma’)->findBy(array( ‘publicado’ => true )); $idiomasarray = array(); foreach ($idiomas as $idioma) { $idiomasarray[] = $idioma->getCodigo(); }
// Consulta los lenguajes preferidos del navegador, comprueba // los que tenemos disponibles disponibles devolviendo el primero // que tenemos disponible de los preferidos por el navegador. $codigoLocale = $request->getPreferredLanguage($idiomasarray);
// Redirigimos la visita a la ruta de abajo poniéndole el código // del idioma. return $this->redirect($this->generateUrl(‘inicio’, array( ‘_locale’ => $codigoLocale ))); } /** * En esta ruta ya tenemos un código de idioma establecido, * podemos hacer a partir de aquí todo. El resto de rutas de la aplicación * deben tener la ruta de la forma «/{_locale}/resto/de/la/ruta» * para continuar navegando en el idioma actual. * * @Route («/{_locale}/», name=»inicio») * @Template */ public function inicioAction($_locale) { $manager = $this->getDoctrine()->getManager(); // Aquí tenemos ya el código de idioma en la variable especial $_locale // con esto ya podemos consultar la BD con el idioma que tenemos en curso // mostrándole al usuario todo traducido o lo que sea que necesitemos hacer.
return array(); } }
A partir de aquí ya tendremos la visita con el idioma. La variable _locale es una variable especial. Se puede consultar en las plantillas Twig poniendo en la plantilla:
{{ app.request.locale }}
La variable _locale es especial porque se establece a partir del momento en que la establecemos nosotros. Se nos puede ocurrir obtener el _locale de la aplicación con la instrucción siguiente en el controlador:
$this->getRequest()->getLocale();
Si hacemos esto en el controlador, en la ruta «iniciototal», no obtendremos el _locale del navegador, si no que obtendremos el _locale puesto en el fichero de parámetros de configuración parameters.yml. A mi me ha pasado y lleva a confusión. Podemos usar ésta última instrucción y tendremos el código de idioma actual si lo hemos establecido recibiendo el _locale en la ruta poniendo siempre al principio del resto de las rutas el _locale. Como indico en el comentario del código, usando rutas de la forma «/{_locale}/resto/de/la/ruta». Es decir, tendremos que recibir la variable {_locale} en todas las rutas para poder usar en el controlador:
$this->getRequest()->getLocale();
.. y que nos devuelva correctamente el idioma. Si lo que queremos es ver el _locale que nos pide el navegador podemos ejecutar lo siguiente:
¿Qué pasa si tienes un proyecto con librerías gestionadas con #Composer y le has puesto muchas de ellas que se actualicen a la última versión disponible?
Para mantener el programa actualizado, beneficiándote de las últimas mejoras de cada librería, era una buena solución. Poner todo a la versión ‘dev-master’. Jeje, todo va bien mientras estás desarrollando..
De vez en cuando alguna función ‘deprecated’ deja de existir porque definitivamente la eliminaron. Nuevas funciones o propiedades que podemos usar. La aplicación funciona cada vez mejor pero sabes que no hay otra que fijar las versiones si no cuando pasemos a producción es un riesgo que se actualice automáticamente y zas! dejó de funcionar. Así que hay que buscar la versión que tenemos instalada de cada paquete y fijarlas.
Puede que tengamos un composer.json parecido a éste, con muchos ~ * @dev dev-master >= etcétera:
Por ejemplo, la primera línea sobre el requerimiento de php no depende de nosotros sino de la versión instalada en el servidor. Así que vamos a la segunda, la de symfony/symfony.
Ahora mismo el proyecto funciona, así que ejecutamos lo siguiente en un terminal o línea de comandos:
$ composer show -i
Si no lo tenemos instalado globalmente entonces:
$ php composer.phar show -i
En éste caso me puede haber salido algo como lo siguiente:
aws/aws-sdk-php 2.7.2 AWS SDK for PHP - Use Amazon Web Services in your PHP project
craue/formflow-bundle dev-master a88ecba Multi-step forms for your Symfony2 project.
doctrine/annotations v1.2.1 Docblock Annotations Parser
doctrine/cache v1.3.1 Caching library offering an object-oriented API for many cache backends
doctrine/collections v1.2 Collections Abstraction library
doctrine/common v2.4.2 Common Library for Doctrine projects
doctrine/data-fixtures dev-master ac36ccc Data Fixtures for all Doctrine Object Managers
doctrine/dbal v2.4.3 Database Abstraction Layer
doctrine/doctrine-bundle v1.2.0 Symfony DoctrineBundle
doctrine/doctrine-fixtures-bundle dev-master 9a5b528 Symfony DoctrineFixturesBundle
doctrine/inflector v1.0 Common String Manipulations with regard to casing and singular/plural rules.
doctrine/instantiator 1.0.4 A small, lightweight utility to instantiate objects in PHP without invoking their constructors
doctrine/lexer v1.0 Base library for a lexer that can be used in Top-Down, Recursive Descent Parsers.
doctrine/orm v2.4.6 Object-Relational-Mapper for PHP
friendsofsymfony/user-bundle dev-master 9714a92 Symfony FOSUserBundle
guzzle/guzzle v3.9.2 Guzzle is a PHP HTTP client library and framework for building RESTful web service clients
incenteev/composer-parameter-handler v2.1.0 Composer script handling your ignored parameter file
jdorn/sql-formatter v1.2.17 a PHP SQL highlighting library
knplabs/knp-components 1.3.1 Knplabs component library
knplabs/knp-menu dev-master d6f3cc4 An object oriented menu library
knplabs/knp-menu-bundle dev-master bdfc95d This bundle provides an integration of the KnpMenu library
knplabs/knp-paginator-bundle dev-master 701dffe Paginator bundle for Symfony2 to automate pagination and simplify sorting and other features
kriswallsmith/assetic v1.2.0 Asset Management for PHP
liip/functional-test-bundle dev-master eb42b04 This bundles provides additional functional test-cases for Symfony2 applications
liuggio/ExcelBundle dev-master 22a2a74 This is a Symfony2 Bundle helps you to read and write Excel files (including pdf, xlsx, odt), thanks to the PHPExcel library
monolog/monolog 1.11.0 Sends your logs to files, sockets, inboxes, databases and various web services
mopa/bootstrap-bundle dev-master a0ee4e8 Easy integration of twitters bootstrap into symfony2
mopa/composer-bridge v1.3.0 Symfony2 Composer Bridge
phpoffice/phpexcel 1.8.0 PHPExcel - OpenXML - Read, Create and Write Spreadsheet documents in PHP - Spreadsheet engine
phpunit/php-code-coverage 2.0.11 Library that provides collection, processing, and rendering functionality for PHP code coverage information.
phpunit/php-file-iterator 1.3.4 FilterIterator implementation that filters files based on a list of suffixes.
phpunit/php-text-template 1.2.0 Simple template engine.
phpunit/php-timer 1.0.5 Utility class for timing
phpunit/php-token-stream 1.3.0 Wrapper around PHP's tokenizer extension.
phpunit/phpunit 4.2.6 The PHP Unit Testing framework.
phpunit/phpunit-mock-objects 2.3.0 Mock Object library for PHPUnit
psr/log 1.0.0 Common interface for logging libraries
sebastian/comparator 1.0.1 Provides the functionality to compare PHP values for equality
sebastian/diff 1.2.0 Diff implementation
sebastian/environment 1.2.0 Provides functionality to handle HHVM/PHP environments
sebastian/exporter 1.0.2 Provides the functionality to export PHP variables for visualization
sebastian/version 1.0.3 Library that helps with managing the version number of Git-hosted PHP projects
sensio/distribution-bundle v3.0.8 Base bundle for Symfony Distributions
sensio/framework-extra-bundle v3.0.2 This bundle provides a way to configure your controllers with annotations
sensio/generator-bundle v2.4.0 This bundle generates code for you
sensiolabs/security-checker v2.0.0 A security checker for your composer.lock
swiftmailer/swiftmailer v5.3.0 Swiftmailer, free feature-rich PHP mailer
symfony/assetic-bundle v2.5.0 Integrates Assetic into Symfony2
symfony/monolog-bundle v2.6.1 Symfony MonologBundle
symfony/swiftmailer-bundle v2.3.7 Symfony SwiftmailerBundle
symfony/symfony v2.5.6 The Symfony PHP framework
twbs/bootstrap dev-master e27dc5d The most popular front-end framework for developing responsive, mobile first projects on the web.
twig/extensions v1.2.0 Common additional features for Twig that do not directly belong in core
twig/twig v1.16.2 Twig, the flexible, fast, and secure template language for PHP
Viendo la línea de symfony/symfony vemos que tenemos instalada la versión 2.5.6. Entonces podemos ir a nuestro fichero composer.json y cambiar el 2.5.* por 2.5.6 así siempre sabremos que no se actualizará a la versión 2.5.7 y sucesivas. Evitando así esos posibles fallos.
Así sucesivamente.
Hay versiones que siguen estando a dev-master al ejecutar ‘composer show -i’. No queda otra que ir viendo uno a uno en sus webs, a ver cuál es la última versión disponible e ir probando si al fijarla continúa funcionando nuestro proyecto.
Usando composer install en vez de update
Otra opción que tenemos es usar ‘composer install’. Lo que hacemos haciendo ‘install’ en vez de ‘update’ es usar la versión exacta que tengamos en el fichero composer.lock es en vez de comprobar las versiones disponibles, descargar las últimas permitidas y así arriesgarnos a que luego deje de funcionar.
Hay que ir viendo un término intermedio entre fijar las librerías a una cierta versión con lo que te quedas sin las últimas mejoras pero ganas estabilidad, o pones las librerías a dev-master con lo que te puedes pasar mucho tiempo «acomodando» las nuevas funcionalidades de cada librería a la aplicación pero ganarás que tu aplicación tendrá todo lo nuevo.
Resumiendo, en local deberíamos siempre de ir actualizando las librerías. Usando ‘composer update’ de vez en cuando para mantener nuestro programa actualizado. Comprobamos que todo funcione y cuando estamos seguros subimos el fichero composer.lock al repositorio para hacer ‘composer install’ en el despliegue.
Además, si ejecutamos en el despliegue:
$ composer install –prefer-dist
sólo te descargará lo necesario para que tu aplicación funcione con lo que descargará bastante menos y la aplicación será más ligera.
Estoy ahora curioseando los entresijos de PHP. Viendo hacia dónde tiende la programación en la web. Añadiendo herramientas, librerías de programación para mis proyectos.
Dentro del mundo de la programación, elegir librerías, actualizarlas, combinarlas.. todo esto lleva trabajo y en los últimos años están apareciendo herramientas que nos facilitan la vida.
Pongámonos en situación
Cuando empezamos a programar con PHP. Desde el inicio hasta hace pocos años, que casi todo se hacía a pelo. PHP puro y duro, añadiendo código y más código. Los programas iban creciendo y creciendo. Se iban añadiendo manualmente librerías para todo tipo de tareas. Ahora ya no tenemos que reinventar la rueda. Estan surgiendo librerías públicas como por ejemplo Packagist, donde se recopilan códigos para hacer todo tipo de tareas con PHP.
Para manejo de Packagist tenemos una herramienta llamada Composer, con la que una vez configurado lo que vamos a necesitar Composer se encarga de conectar a Packagist y descargar los ficheros que haga falta. Para la programación front-end tenemos herramientas como Bower, similar a Composer, pero pensado para gestionar librerías Javascript/CSS. Estas herramientas, una vez configuradas, nos descargarán los ficheros a nuestro directorio de trabajo y listo. Ya tendremos nuestro proyecto para programar, podremos añadir o borrar librerías fácilmente, elegir versiones, actualizar todo..
Para éste post he elegido probar Silex, es un framework bien sencillo. Más bien un micro-framework como lo nombran oficialmente. Está construido a base de componentes del gran framework Symfony. Con él tendremos una serie de herramientas para usar como plantillas Twig, podremos enviar emails con Swiftmailer, si no eres un experto en seguridad (como es mi caso) no pasa nada porque tenemos el componente de seguridad Security, el componente para generar formularios Form, el generador de URLs, etcétera.
Como iba diciendo, Composer se va a encargar de gestionar por nosotros las librerías PHP de nuestro proyecto. Con el ejemplo veremos mejor cómo funciona. Prepararemos nuestro proyecto hola mundo con Silex con Composer y veremos qué sencillo que lo tenemos para aumentar luego librerías. Pasos:
Descargamos el fichero composer.phar
Preparamos nuestro fichero composer.json
Ejecutamos Composer.
Empezamos a programar.
Descargamos el fichero composer.phar
En el directorio donde vayamos a desarrollar nuestro proyecto o queramos hacer éstas pruebas debemos de poder usar Composer. Se puede instalar en el sistema, en el PATH del sistema, pero eso ya se sale del post. La forma sencilla que viene en su web oficial es poniendo el fichero composer.phar en el directorio. Si tienes curl ejecutas lo siguiente:
curl -sS https://getcomposer.org/installer | php
Si sólo tienes PHP, puedes ejecutar lo siguiente en línea de comandos y se te descargará el fichero:
No lo he dicho pero supongo que ya tienes instalado PHP. Sino desde su web puedes instalarlo: http://es1.php.net/downloads.php. Si tienes Linux, en mi caso Ubuntu, basta con poner en línea de comandos ‘sudo apt-get install php5’.
Preparamos nuestro fichero composer.json
Para Silex va a ser muy sencillo. Si queremos elegir librerías no tenemos más que ir a Packagist y añadir las que necesitemos. El fichero:
En el mismo directorio raiz donde tenemos el composer.phar creamos éste fichero composer.json con el contenido de aquí encima. Si nos fijamos he puesto dev-master aquí arriba, esto nos descargará siempre la última versión que haya disponible. He añadido phpoffice/phpexcel, para hacer una prueba a ver qué tal.
Ejecutamos Composer
Entonces la primera vez tenemos que ejecutar una instalación de las librerías en linea de comandos:
php composer.phar install
Veremos entonces algo parecido a lo que hay en la imagen inicial. Si estamos modificando el fichero composer.json debemos entonces ejecutar lo siguiente:
php composer.phar update
Si todo ha ido bien entonces tendremos en nuestro directorio los siguientes ficheros: composer.phar, composer.json, composer.lock y el directorio vendor. El fichero composer.lock es un fichero que se actualiza para llevar sus tareas internas cada vez que ejecutamos Composer. Luego en el directorio vendor/ tendremos todas las librerías actualizadas a la versión.
Empezamos a programar
No lo he dicho antes pero dentro del directorio de las librerías (vendor), tendremos ahora un fichero autoload.php que simplemente lo incluimos o requerimos y a programar. Tendremos acceso a todas las librerías de Composer que hayamos incluido. Con un ejemplo se verá más claro:
<?php
// index.php
ini_set('display_errors', 'On');
error_reporting(E_ALL);
require_once __DIR__.'/vendor/autoload.php';
$app = new SilexApplication();
$app->get('/', function () {
return 'Página inicial.';
});
$app->get('/crearTexto', function () {
$nombreArchivo = 'fichero.odt';
$phpWord = new PhpOfficePhpWordPhpWord();
$section = $phpWord->addSection();
$section->addText('Hello world!');
$section->addText('Hello world! I am formatted.',
array('name'=>'Tahoma', 'size'=>16, 'bold'=>true));
$phpWord->addFontStyle('myOwnStyle',
array('name'=>'Verdana', 'size'=>14, 'color'=>'1B2232'));
$section->addText('Hello world! I am formatted by a user defined style',
'myOwnStyle');
$objWriter = PhpOfficePhpWordIOFactory::createWriter($phpWord, 'ODText');
$objWriter->save($nombreArchivo);
$str = 'Fichero de Word en formato Open Document creado.';
$str .= '<a href="' . $nombreArchivo . '">Haz click aquí para descargar</a>';
return $str;
});
$app->run();
Ahora vamos a arrancar el servidor web interno de PHP para probar la pequeña aplicación. Ejecutamos en línea de comandos estando en el directorio del proyecto:
php -S localhost:8000
He usado el ejemplo del libro oficial en castellano sobre Silex, modificándolo para ésta prueba. Si quieres puedes ver toda la documentación de Silex en http://librosweb.es/silex/
Si todo ha ido bien, ejecutando http://localhost:8000/ veremos el mensaje ‘Página inicial.’. Si ejecutamos http://localhost:8000/crearTexto veremos el segundo mensaje, en donde se habrá creado el fichero de texto fichero.odt y podremos descargarlo. Si vemos nuestro directorio del proyecto ahí lo tendremos. En el ejemplo he seguido la documentación de su página oficial para crear dicho fichero.
Resumiendo
¿Qué sencillo usar las librerías para hacer algo tan complejo como un fichero compatible con Word? En casi 40 líneas de código tenemos una aplicación web que crea dicho fichero. Todo gracias a usar dos librerías de Composer y en seguida ya lo tenemos.
Recapitulando, ponemos en el fichero composer.json las librerías que vayamos a usar. Luego incluimos el fichero /vendor/autoload.php y ya tenemos todas las clases de objetos listos para usar. Te ahorra tiempo, es práctico, organizado. Si no estás ya usando los vendors deberías de hacerlo.
