CodeIgniter, el peso pluma de los frameworks PHP
Equipo editorial de IONOS
CodeIgniter es preferido como framework para aplicaciones web por los desarrolladores que priorizan la velocidad a un abanico avanzado de funciones. El objetivo central que ha guiado el diseño de este entorno de desarrollo PHP de código abierto es, según la página web del proyecto, obtener el máximo en rendimiento y flexibilidad con un mínimo de código.
¿Qué es CodeIgniter?
Es un entorno de desarrollo web escrito en PHP que presume de acelerar y optimizar el desarrollo de aplicaciones web gracias a un compacto diseño de software. La compañía de software norteamericana EllisLab fue la encargada de su creación y de la publicación de su primera versión en febrero de 2006. Un año después de anunciar, el 9 de julio de 2013, que la compañía ya no disponía de los recursos necesarios para continuar desarrollando el software, el proyecto se vio beneficiado por su adquisición por el British Columbia Institute of Technology (BCIT). El código fuente de CodeIgniter es distribuido con una licencia MIT y puede descargarse desde la plataforma GitHub. La última versión estable del entorno de desarrollo, CodeIgniter 3.1.2, se ofrece para su descarga gratuita en la página oficial del proyecto.
La estructura de CodeIgniter
El diseño orientado al rendimiento de este framework de desarrollo web se revela en su parca arquitectura, pues se basa en el patrón Modelo-Vista-Controlador (MVC). El principio fundamental que sustenta a la arquitectura de desarrollo MVC es la estricta separación entre el código y la presentación, gracias a una estructura modular de software y a la externalización del código PHP. Esta separación se realiza en estos tres grupos: el modelo (model), la vista (view) y el controlador (controller), que explicamos a continuación:
- El modelo representa la estructura de datos de una aplicación web desarrollada con CodeIgniter. Para ello, en el código fuente se definen las denominadas clases (“model classes”), que contienen funciones especiales con las cuales se puede recibir, insertar o actualizar la información de la base de datos.
- La vista es aquello que se le presenta al usuario final. Por lo general, se trata de un documento HTML en el cual se ha insertado contenido de forma dinámica con PHP, convirtiéndose en una especie de plantilla. CodeIgniter también permite definir fragmentos de una página web como la cabecera y el pie de página o páginas RSS como vista. Normalmente las aplicaciones web utilizan varias vistas, que toman su contenido desde el mismo modelo, de tal forma que es posible presentar diversas características del programa en vistas diferentes.
- El controlador media entre el modelo, la vista y cualquier otro recurso necesario para procesar una petición HTTP o generar una página web de forma dinámica. Este componente recibe las peticiones entrantes, valida la entrada, selecciona la vista deseada y le entrega el contenido que el modelo ha cargado desde una base de datos.
En este esquema se aprecia claramente cómo se produce la interacción en la arquitectura MVC:
La estructura MVC permite diseñar software de forma flexible, ya que se pueden substituir, editar y reutilizar los módulos individuales de programación muy fácilmente. Los cambios que se realizan en un componente no suelen tener ningún efecto en el código fuente de otros componentes, siempre y cuando estos cambios no tengan lugar en los puntos de contacto entre unos y otros.
La mencionada división entre la lógica del programa y la presentación resulta en un código claro y bien estructurado. Esto es lo que hace que las aplicaciones web diseñadas según un patrón MVC estén consideradas como fáciles de mantener, puesto que, en caso de error o fallo, la fuente suele encontrarse en uno solo de los componentes. Esta separación también permite desarrollar la lógica y el diseño de forma independiente. Si los desarrolladores del backend y del frontend trabajan en paralelo, las aplicaciones se pueden terminar mucho más rápidamente.
Aun cuando CodeIgniter utiliza el patrón MVC, los usuarios no están obligados a hacerlo por completo. Si el controlador y la vista son componentes obligatorios, no sucede lo mismo con el modelo, cuyo uso como vínculo con la base de datos es meramente opcional. Una aplicación realizada con CodeIgniter también puede realizarse, además, con una arquitectura MVC jerárquica (HMVC), que ampliaría el patrón MVC clásico con una lógica jerárquica.
Entendiendo el flujo de aplicación de CodeIgniter
El framework PHP CodeIgniter funciona con un URL: para dirigirse al controlador, como unidad de control central entre la vista y el modelo, es necesario introducir un URL en la barra de búsqueda del navegador web. Para ello, los desarrolladores crean las denominadas clases de controlador, archivos PHP con diversas funciones que permiten cargar librerías, extensiones o helpers, establecer conexiones a bases de datos, integrar un modelo o seleccionar una vista determinada.
El flujo de aplicación de CodeIgniter se basa en el siguiente esquema de URL básico:
example.com/class/function/parameter
Al dominio (example.com) le sigue una clase de controlador, a la cual hay que dirigirse, así como una función de controlador específica. El esquema lo cierran los parámetros opcionales, que se utilizan para asignar al controlador seleccionado ciertos identificadores o variables.
En la práctica, un URL de CodeIgnites podría tener esta construcción:
example.com/news/article/511
Este URL se dirige al controlador news en el dominio example.com y le solicita ejecutar la función article, para, por ejemplo, cargar una vista homónima para la vista de artículo. Los parámetros opcionales, que se entregan al controlador con el URL, son los encargados de indicar qué contenido se ha de solicitar de la base de datos con el modelo, en este caso un artículo identificado como 511.
En la configuración de salida, CodeIgniter ejecuta el index.php en cada URL de la aplicación:
example.com/index.php/news/article/511
Este archivo PHP contiene información sobre el lugar donde se encuentran los archivos centrales del framework, así como las librerías, extensiones o helpers integrados y sobre el directorio donde están depositados los archivos de la aplicación. El archivo index.php también sirve para inicializar todos los recursos básicos.
Si CodeIgniter se ejecuta en un servidor Apache HTTP, se puede eliminar el index.php de la dirección de la aplicación con mod_rewrite, para mostrar al usuario y a los crawlers del buscador direcciones web “limpias”. Los desarrolladores añaden el siguiente código en el archivo .htaccess del servidor web:
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]La estructura fundamental del framework se apoya en primera instancia en clases de controlador, clases de modelo y plantillas de vista.
Clases de controlador
CodeIgniter permite a los desarrolladores programar controladores individuales como clases definidas por el usuario. Para ello crean un archivo PHP separado para cada controlador en el directorio application/controllers/. Los controladores encierran la lógica de programación propia de una aplicación web desarrollada con CodeIgniter y se crean como subclases de la clase CI_Controller. En el código fuente se realiza con ayuda de la palabra clave extends.
class News extends CI_Controller {
}Como clase subordinada, News hereda todas las funciones de la visibilidad public y protected de la clase CI_Controller.
las palabras clave public, protected o private ayudan a definir la visibilidad de una propiedad o funciones en PHP. Si un elemento se declara como public, todas las clases de un software tienen acceso a él. Si este acceso a clases padre y a sus respectivas subclases ha de limitarse, se utiliza la palabra clave protected. Y si un elemento es declarado private, solo está disponible a la clase que define el elemento.
Cada clase de controlador definida por el usuario también ha de contener una función constructor, con la cual se pueden integrar librerías, un modelo de datos, bases de datos o clases helper. Desde PHP5, se utiliza __construct() como estándar.
<?php
class News extends CI_Controller {
public function __construct() { //define el constructor
parent::__construct(); //invoca al constructor de la clase superior
$this->load->helper('url'); //carga una clase helper para el trabajo con URL
$this->load->helper('file'); // carga una clase helper para el trabajo con archivos
$this->load->database(); //carga una base de datos
$this->load->model('News_model'); //carga un modelo con el nombre „News_model“
}
?>Este ejemplo, con explicaciones a cada línea de código, muestra la clase News como subclase de CI_Controller. La función constructor __construct() comprende e integra dos clases helper, una base de datos y el modelo de datos News_model.
Todas las clases de controlador que se definen en PHP para CodeIgniter se tienen que escribir con mayúscula inicial (News en lugar de news). En cambio, en la dirección URL se escriben con minúscula.
Funciones del controlador
Una vez fijada la estructura básica del controlador definido por el usuario, el siguiente paso es continuar con la verdadera lógica de programación en la forma de funciones del controlador, con las cuales se invocan vistas o se interacciona con un modelo de datos integrado.
Para permitir que el controlador cargue una vista, el documento HTML base se ha de guardar como archivo PHP en el directorio application/views/. Una vista sencilla para la página de un artículo podría tener el siguiente código:
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="utf-8">
<title><?php echo $title; ?></title>
</head>
<body >
<h1><?php echo $headline ?></h1>
<p><?php echo $content_body ?></p>
</body>
</html>los documentos HTML que contienen código PHP se deben guardar como documento PHP (.php). Solo así se garantiza que el intérprete de PHP del servidor web ejecute los scripts y no entregue el código PHP como texto plano.
Es necesario crear una función para poder cargar una vista en el controlador. En el siguiente ejemplo vemos como la función article() se utiliza para cargar la vista article.php:
public function article() {
if (!file_exists(application/views/article.php)) {
show_404();
}
$this->load->view('article');
}Este fragmento de código se lee de la siguiente forma: en primer lugar, CodeIgniter comprueba que el directorio application/views/ contenga un archivo con el nombre article.php. Esta solicitud se realiza mediante la partícula lingüística if y la condición negadora (!) file exists (). Si se da esta condición y no se encuentra este archivo en el directorio, if devuelve el valor TRUE y CodeIgniter ejecuta la función show_404() indicada en la línea siguiente a if. Al usuario se le informaría entonces de la inexistencia de este archivo solicitado. Si la condición if no se cumple y !file_exists se evalúa como FALSE, entonces CodeIgniter ejecuta la función $this->load->view('article'), con la cual se carga en la aplicación el archivo correspondiente como vista.
Siempre y cuando el archivo solicitado tenga formato PHP, este puede ser escrito sin sufijo en la función view(), pero si se tienen que cargar otros formatos entonces es obligatorio indicar el sufijo.
CodeIgniter suele utilizarse en aplicaciones web dinámicas, que muestran a los usuarios páginas web generadas de forma dinámica en lugar de páginas HTML estáticas. Esto es posible si los datos que contiene la vista se corresponden con los parámetros que CodeIgniter recibe con la dirección URL.
example.com/news/article/511
Hasta ahora, con la función $this->load->view('article') solo se ha cargado una visualización para el artículo. Ahora se tratará de integrar el contenido vinculado al parámetro 511, dando por supuesto que esta cifra identifica a un determinado texto mediante un sistema de gestión de bases de datos. Para poder cargarlo en el programa desde la base de datos se ha de completar el ejemplo anterior de tal forma que se invoque al modelo integrado en la función __construct().
public function article($id) {
if (!file_exists(application/views/article.php)) {
show_404();
}
$data = $this->News_model->get_data($id);
$this->load->view('article', $data);}El argumento de función entregado en primer lugar, aquí con el nombre de variable $id, corresponde al identificador en el URL (511 en nuestro ejemplo). La función de modelo get_data() sirve para cargar desde la base de datos el contenido vinculado al identificador. El método view() invoca la vista article y le transfiere los datos en la forma de array asociativo ($data). El modelo News_model entrega así al controlador News los datos seleccionados que este ha entregado a la vista.
Todas las operaciones que tienen que ver con la petición de datos se almacenan en el modelo involucrado en ella.
Clases modelo
En CodeIgniter los modelos se utilizan para preparar funciones con las cuales ejecutar operaciones con la base de datos. Exactamente igual que con las clases controlador, las clases modelo también se pueden definir libremente en el framework.
Para crear una clase modelo primero se le asigna un nombre, en este caso News_model. Igual que las clases controlador, todas las clases modelo que se definen son subclases de la clase padre CI_Model. La herencia se realiza mediante la clave extends. Las clases modelo también integran bases de datos y otros recursos con la función _construct().
class News_model extends CI_Model {
public function __construct() {
parent::__construct();
$this->load->database();
}
}A esta estructura básica le siguen las llamadas funciones modelo, en las cuales los programadores definen todas las operaciones de bases de datos que el controlador ha de entregar a través del correspondiente modelo.
Funciones modelo
Las clases modelo permiten a los desarrolladores definir funciones de forma individual para las operaciones de bases de datos. En un ejemplo anterior se utilizó la función get_data() en la clase controlador News para cargar contenido desde la base de datos a la vista. Ahora se define en el modelo qué operaciones de base de datos se ocultan tras esta función.
class News_model extends CI_Model {
public function __construct() {
parent::__construct();
$this->load->database();
}
public function get_data($id) {
$this->db->select('content');
$this->db->from('example_table');
$this->db->where('id', $id);
$query = $this->db->get();
return $query->result();
}En la clase modelo News_model se define la función get_data() como operación de base de datos (db), que solicita la columna del registro indicada con select() con el identificador $id desde la tabla indicada en from() mediante get() y la devuelve como array de datos con ayuda de la función result(). Un modelo de datos dispone generalmente de una gran variedad de funciones modelo. Los desarrolladores recurren para ello a la clase Query Builder, que abarca una serie de funciones predefinidas para operaciones base de datos clásicas. En la página web oficial de CodeIgniter puedes obtener una impresión general.
Enrutamiento con CodeIgniter
La dirección URL indica a CodeIgniter qué clases y funciones controlador han de ser invocadas. Para ello, el framework utiliza el esquema clase/función/parámetro, un esquema básico que se puede modificar según las necesidades. CodeIgniter dispone del archivo routes.php en el directorio application/config/ que contiene un array denominado $route, que es el que permite a los desarrolladores definir sus propios criterios de enrutamiento.
La configuración de salida incluye tres entradas estándar en el array $route: el controlador estándar, una regla de enrutamiento para el error 404 (enlace roto) y una regla para la substitución automática del guion (-) por el guion bajo (_):
$route['default_controller'] = 'home/welcome';
$route['404_override'] = 'home/welcome';
$route['translate_uri_dashes'] = FALSE;La primera entrada estándar determina el controlador de la aplicación que CodeIgniter cargará si un URL no contiene más información de enrutamiento aparte del dominio. En este ejemplo, la regla de enrutamiento define la clase controlador home como controlador estándar. Así, los usuarios que no proporcionan información sobre la página web a la que se dirigen en la dirección son redirigidos a home y reciben la vista welcome. Lo habitual es redirigir al usuario a la página principal. Si no se define ningún controlador estándar, CodeIgniter muestra una página de error 404.
La segunda entrada en el array $route define a un controlador al cual se llama si el controlador invocado con el URL no se ha podido encontrar en los archivos de la aplicación. La regla de enrutamiento $route['404_override'] = 'home' sobrescribe la página de error 404 habitual, para reenviar al usuario a la clase controlador home.
Por último, la tercera entrada en el array $route impide que se produzcan errores de enrutamiento por culpa del guion. Dado que el guion no es un signo válido para nombres de clases y funciones, en la configuración estándar ya se sustituye automáticamente.
Cuando se requiere crear una regla de enrutamiento nueva para una dirección dinámica, los desarrolladores web disponen con CodeIgniter de dos opciones: definir entradas de enrutamiento para URL dinámicos con Wildcards (comodines) o con expresiones regulares.
El documento routes.php soporta dos tipos de comodín:
Las páginas web con un buen número de páginas de error 404 son difíciles de rastrear por los crawlers del buscador, dificultando a los buscadores acceder al contenido relevante. Esto puede tener, además de efectos en la experiencia de usuario, una influencia negativa en la clasificación en los buscadores. En consecuencia, los desarrolladores web tienen mucho interés en evitar páginas de error de este tipo.
| Comodines de routes.php | Descripción |
|---|---|
| :num | Actúa de comodín para números enteros |
| :any | Actúa de comodín para una cadena de caracteres (string) |
El siguiente ejemplo ilustra una entrada en el routes.php que permite eliminar la función (article) del URL:
$route['news/article/(:num)'] = 'news/$1';Gracias al comodín :num se selecciona el parámetro de una dirección dinámica y se almacena en la variable $1. Siempre y cuando se definan reglas de enrutamiento con :num o :any, estas se tienen que cerrar con paréntesis.
El routes.php también acepta, por otro lado, reglas de enrutamiento como expresiones regulares. Estos dos tipos de comodín se pueden escribir entonces de esta manera:
:num equivale a \d+
:any equivale a [^/]+Así, una forma alternativa de escribir la dirección de arriba sería esta:
$route['news/article/(\d+ )'] = 'news/$1';También las expresiones regulares se escriben en el routes.php entre paréntesis.
El flujo de aplicación en CodeIgniter: síntesis final
La siguiente ilustración resume el flujo de aplicación de una aplicación basada en CodeIgniter en siete pasos:
Y ahora, paso a paso:
1. El archivo index.php sirve a CodeIgniter como primer controlador de las solicitudes HTTP entrantes. Es en este punto donde se inicializan todos los recursos básicos necesarios para ejecutar la aplicación.
2. En el enrutamiento, CodeIgniter comprueba qué acción se debe ejecutar. Para ello, la aplicación compara la dirección de la solicitud con las reglas de enrutamiento comprendidas en el routes.php.
3. Al enrutamiento le sigue el caching. Si en la memoria caché se encuentra una respuesta adecuada a la petición, esta se envía directamente al navegador que la ha realizado. En caso contrario, se ejecuta el controlador indicado durante el enrutamiento tras activar la función de filtrado.
4. CodeIgniter contiene un filtro integrado que capta peticiones maliciosas. Antes de que la aplicación cargue un controlador ajustado a la solicitud, cada petición HTTP se somete a una prueba de seguridad.
5. Si la petición supera el filtrado se ejecuta el controlador. Este selecciona la vista adecuada y carga el modelo, así como todas las librerías, clases helfer, plugins y scripts necesarios para poder responder la petición.
6. Tan pronto la vista ha recibido todos los datos relevantes, puede entregarlos al navegador.
7. Si se ha activado el cacheo, CodeIgniter conserva temporalmente los datos salientes para responder peticiones repetitivas directamente.
Ventajas de utilizar CodeIgniter
Con más de 14.000 estrellas en GitHub, CodeIgniter es un proyecto de desarrollo con una reputación remarcable, situado en el tercer puesto de los frameworks de PHP más populares. Sin embargo, como cualquier software, CodeIgniter tiene tanto ventajas como inconvenientes que han de considerarse antes de decidirse por él.
Estas son las ventajas de CodeIgniter:
- Configuración de escasa dificultad: es fácil empezar a trabajar con CodeIgniter. Sus usuarios no necesitan demorarse excesivamente en la configuración del framework, sino que, casi inmediatamente después de instalarlo, pueden empezar con el desarrollo de la aplicación. Los ajustes se reducen esencialmente al documento config.php en el directorio application/config/. Aquí, los usuarios del framework definen una ruta estándar para el acceso desde el navegador, una clave para el cifrado, un nombre para la cookie de sesión y los ajustes para el Cross-Site-Scripting (XSS). Sería oportuno también crear un archivo .htaccess para poder eliminar el index.php de la dirección de la aplicación con RewriteRule, así como es necesario configurar la conexión con la base de datos que se introduce en el archivo database.php.
- Small Footprint: CodeIgniter deja una huella muy pequeña en el sistema, pues el paquete de descarga del framework solo alcanza los 11 MB, con 9 MB ocupados únicamente en la detallada documentación del software. El motivo del reducido tamaño del código radica en que el sistema básico del framework solo incluye un par de bibliotecas. Todos los recursos adicionales necesarios se pueden instalar a posteriori.
- Rendimiento excepcional: esta estructura básica tan simple lleva a CodeIgniter a superar a otros frameworks PHP en velocidad, algo ya alabado en su momento por el inventor de PHP Rasmus Lerdorf, entre otros. Lerdorf sorprendió en 2008 a propios y extraños declarando, en la Free and Open Source conference (FrOSCon), que CodeIgniter le gustaba por ser “más rápido, más ligero y menos parecido a un framework” (“because it is faster, lighter and the least like a framework“”. En lugar de implementar el acceso a las páginas dinámicas mediante Query Strings como hacen otros frameworks PHP, CodeIgniter se inclina por un principio basado en segmentos:
- URL limpios: CodeIgniter genera automáticamente direcciones legibles para hombres y máquinas. En lugar de implementar el acceso a las páginas dinámicas mediante Query Strings como hacen otros frameworks PHP, CodeIgniter se inclina por un principio basado en segmentos:
URL con Query String: example.com?controller=news&function=article&id=511
URL en segmentos: example.com/news/article/511
- Estilo de programación libre: el framework PHP se basa en una interpretación libre de la arquitectura MVC, lo que tiene como consecuencia que los desarrolladores sean libres en cuanto al estilo de programación que quieran utilizar.
- Documentación amplia y detallada: CodeIgniter pone a disposición de sus usuarios una completa documentación en inglés, incluyendo un manual para principiantes, disponible como guía online y versión para descarga en la página web del proyecto. Su código fuente es, además, claro y está bien comentado.
- Comunidad de soporte: cualquier desarrollador que utilice CodeIgniter para programar aplicaciones cuenta con el apoyo de otros usuarios, pues el proyecto está acompañado de una comunidad muy activa que incluye un foro público. Actualmente, más de 8.143 miembros participan en unos 65.000 hilos en los que intercambian comentarios y opiniones sobre el uso y el ulterior desarrollo del framework.
Desventajas de Codelgniter
Debido a la adquisición de BCIT, el desarrollo del framework se estancó temporalmente y, así, los intentos de los desarrolladores de implementar avances tecnológicos en Codelgniter han sido en vano.
- ORM solo a través de terceros: el mapeo objeto-relacional (object relational mapping, ORM) se refiere a una técnica de desarrollo de software que permite a las aplicaciones almacenar objetos escritos en un lenguaje de programación orientado a objetos como PHP en una base de datos relacional. Codelgniter no soporta al ORM de forma nativa. Sin embargo, esta tecnología puede integrarse.
- No cuenta con un motor de plantillas: Codelgniter se enorgullece de funcionar correctamente sin un motor de plantillas. A cambio, este framework ofrece un analizador simple de plantillas. Eso puede ser visto como una ventaja, pues, generalmente, el uso de un motor de plantillas se asocia a una sobrecarga de rendimiento (por encima del tiempo de ejecución). Además, también tendría que aprenderse el lenguaje de la plantilla. Por otro lado, un motor de plantillas permite separar la generación de datos del código para la presentación, generando así un código fuente claramente estructurado. Si se utiliza un motor de plantillas con una sintaxis más ligera, se puede reducir significativamente el tamaño total del código de la aplicación.
- No existen los espacios de nombres: con los espacios de nombres, PHP ofrece la capacidad de separar el código de los diferentes grupos de aplicaciones. Los desarrolladores de PHP hacen uso de esta característica para evitar los conflictos que se producen durante la denominación de las clases y de las funciones, siendo, por ejemplo, muy comunes las colisiones de nombre con clases internas de PHP con funciones, constantes o elementos integrados por terceros. Hasta ahora, Codelgniter no utiliza esta función PHP.
- No cuenta con la opción de autocarga de clases de PHP: con __autoload() y spl_autoload_register(), desde su quinta versión, PHP cuenta con dos funciones que permiten cargar las definiciones de clase automáticamente cuando sea necesario. Esta función no está disponible en Codelgniter.
- Menos bibliotecas incorporadas que otros entornos PHP: gracias al diseño ligero del software, la configuración inicial de Codelgniter proporciona un número significativamente menor de bibliotecas que otros frameworks PHP. En primer lugar, estos incluyen las tareas más importantes de desarrollo web, como el acceso a la base de datos, envío de correo electrónico, validación de datos de formulario, mantenimiento de las sesiones de trabajo o del trabajo con XML – RPC. Para aquellas tareas que van más allá de las funciones básicas, será necesario integrar otras bibliotecas o recursos externos. Ahora bien, esto puede resultar ventajoso para aquellos desarrolladores que están buscando un framework cuyas funciones se reduzcan al mínimo.
Codelgniter para los lectores con prisa
La siguiente tabla resume los puntos clave de este framework:
| CodeIgniter | |
|---|---|
| Desarrollador | British Columbia Institute of Technology (BCIT) |
| Última versión | Versión 3.1.2 |
| Patrón de diseño | MVC/HMVC, Active Record, Chain of Responsibility |
| Conocimientos requeridos | PHP, programación orientada a objetos (OOP) |
| Lenguaje de programación | PHP 5.6 en adelante |
| Licencia | MIT-Lizenz |
| Soporte de base de datos | MySQL (5.1+), Oracle, PostgreSQL, MS SQL, SQLite, CUBRID, Interbase/Firebird, ODBC |
| ORM | Solo a través de terceros |
| Caching | Sí |
| Motor de plantillas | No |
| Espacios de nombres | No |
| Autocarga en PHP | No |
| URL amigables para buscadores | No |
| Características de seguridad | Cross Site Request Forgery (XSRF), Cross Site Scripting (XSS), SQL Injection |
| Biblioteca de pruebas | PHP Unit |
En conclusión: ¿a qué proyectos está dirigido Codelgniter?
Con su diseño compacto y sintaxis amigable para los principiantes, Codelgniter resulta apropiado para quienes aspiren a convertirse en programadores. Ahora bien, quienes ya hayan dado sus primeros pasos en el desarrollo web dinámico basado en PHP, también se familiarizarán rápidamente con este ligero framework. Incluso los desarrolladores experimentados se toparán con una gran flexibilidad, garantizada principalmente gracias a la práctica funcionalidad reducida de este framework PHP. Sin embargo, quien quiera trabajar con Codelgniter deberá acostumbrarse al patrón MVC, así como prescindir de un motor de plantillas y de un ORM nativo. A pesar del reducido tamaño de su código, Codelgniter es una solución ideal para pequeños y grandes proyectos web por igual.
