Caso “URL limpia de CodeIgniter” para Linux, SOLUCIONADO

Hoy en día, somos muchos los desarrolladores que disfrutamos de las bondades de este muy buen framework, pero siempre se ha tenido el problema para quitar esa porcion de url “index.php” de nuestros proyectos.

Bien, pues luego de investigar, buscar y preguntar… y demas cosas, encontre un modo de retirar ese “index.php”, el cual lo trabaje en una distro de Linux.

Pues comencemos:

  • Como sabran, se necesita activar el mod_rewrite en la configuracion de nuestro servidor Apache. Pues se puede hacer manualmente accediendo al archivo de configuracion o simplemente ejecutando el siguiente comando:   sudo a2enmod rewrite
  • Una vez activado el mod_rewrite, procederemos a quitar las restricciones en el archivo:  sudo gedit /etc/apache2/site-enable/000-default , donde reemplazaremos todos los “AllowOverride None” por “AllowOverride All“.
  • Una vez terminado esto, procedemos a reiniciar el servicio de Apache con: sudo /etc/init.d/apache2 restart .
  • Si al reiniciar el servicio de Apache, por casualidad les aparece mensaje como: apache2: Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName , no se preocupen, se soluciona agregando la siguiente linea: ServerName localhost en el apache2.conf.
  • Es hora de comprobar que en nuestro archivo de configuracion  “system/application/config/config.php” , esté ya modificado la opcion del index page, de modo que quede así:  $config[‘index_page’] = “”;
  • Ahora viene lo más importante, y es crear un archivo: .htaccess con el siguiente contenido, en la carpeta donde se encuentra nuestro proyecto, es decir donde se encuentra la carpeta “system”:

        ErrorDocument 404 /index.php

        DirectoryIndex index.php.

        <IfModule mod_rewrite.c>
        RewriteEngine on
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule ^(.*)$ index.php/$1 [L,QSA]
        </IfModule>

Y con esto ya tenemos podemos trabajar sin el poco querido: index.php , es decir, si nuestra url era: http://localhost/proyecto/index.php/controlador ahora sera simplemente http://localhost/proyecto/controlador.

Espero les haya servido este post, ya saben que cualquier consulta, pueden hacerla dejandonos un comentario, y nosotros gustosamente responderemos. Gracias.

Utilizando el Scaffolding

Saludos!

Quizá muchos ya han logrado manejar ésta herramienta que nos ofrece CodeIgniter llamada Scaffolding, pero tambien hay algunos que tienen ciertas dificultades o aun no entienden su concepto.

Pues bien, la herramienta Scaffolding provee una forma rápida y muy sencilla de agregar, editar o borrar información de su base de datos durante el desarrollo de su proyecto.

La configuración es muy sencilla, y se explicará a continuación:

Inicialmente, detallo que he creado una carpeta llamada ” comunidad “, la cual contiene los archivos del CodeIgniter.

Bien, para poder usar el Scaffolding, necesitamos tener una base de datos y al menos una tabla ya creada. En mi caso, mi base de datos es ” comunidad ” y mi tabla es ” cursos “.

Ahora sí, a configurar el CodeIgniter. Primero no dirigimos a: ” system/application/config/config.php ” y definimos nuestra base_url, en mi caso:

$config['base_url'] = "http://localhost/comunidad/";

Luego nos dirigimos a: ” system/application/config/routes.php ” y definimos nuestro scaffolding_trigger, el cual vendría a ser nuestra palabra secreta y cuando se encuentre en la URL, lanzará la interface de scaffolding; en mi caso será: ” admin

$route['scaffolding_trigger'] = "admin";

Antes de continuar, hago recordar que para lograr que ésto funcione, se debe haber ya configurado el archivo ” system/application/config/database.php ” con el hostname, username, password y database ya definidos.

Por último, nos queda usar un controller para cargar el scaffolding. Podemos usar el que nos trae por defecto el CodeIgniter ” welcome ” o creamos uno propio, por ejemplo:

class Home extends Controller{
		function __construct(){
			parent::Controller();
			$this->load->scaffolding('cursos');
		}

		function index(){
			//Lo que aparecera en el index
		}
	}

Expliquemos brevemente el codigo del controlador ” home “. Creo la clase ” Home ” y en el constructor ( en éste caso uso la sintaxis “__construct” pues estoy trabajando con PHP5. En éste contructor, invoco a ” load->scaffolding() ” y le envio el nombre de la tabla que deseo cargar, en mi caso: ” cursos “.  Y listo, ahora ingreso a http://localhost/comunidad/index.php/home/admin y me muestra lo siguiente:

scaffolding

Y ahora pueden agregar, editar o borrar registros de esa tabla. Si mas adelante desean usar otra tabla, solo necesita cambiar el nombre de la tabla al momento de invocar el ” load->scaffolding() ” en su controlador.

NOTA: Scaffolding sólo trabajará con tablas que contengan un primary key, ya que esta información es necesaria pare realizar varias funciones de base de datos.

Espero les haya ayudado este post, y comenten si tienen alguna duda o algo, estamos para ayudarnos.

Gracias!

Usando CodeIgniter en un proyecto real

Recientemente en la empresa para la que trabajo (Sistemas Globales Multimeda, también conocida como SGM Sistemas) se nos planteó un presupuesto, cuanto menos, atractivo e interesante. Tras muchas deliberaciones en torno a qué lenguaje utilizar (ASP o PHP), finalmente nos inclinamos por éste último por varias razones:

  • Mayor cantidad de herramientas disponibles (Eclipse frente a Dreamweaver; MySQL frente a SQL Server; MySQL Workbench para el diseño de la base de datos, PHPMyAdmin y un servidor con Plesk).
  • Más componentes disponibles y a un precio más asequibles (cuando no gratuitos).
  • Mejor separación entre el código y el diseño.

Nuestro equipo de trabajo había tenido de forma reciente buenas experiencias con PHP, logrando reducir los tiempos de desarrollo y aumentando sensiblemente la calidad y reusabilidad de las aplicaciones realizadas.

El proyecto constaba de las siguientes áreas:

  • Extranet con posibilidad de intercambio de documentos.
  • Notificación de disponibilidad de documentos, y de lectura de los mismos vía e-mail.
  • Gestor de contenidos basado en plantillas predefinidas.
  • Gestión de descargas, noticias y galerías.

No es uno de los mayores proyectos a los que nos hemos enfrentado; no obstante, dada la importancia del cliente (una institución pública) el resultado debía ser óptimo, bien probado y en un marco de seguridad importante.

Tras barajar las posibilidades disponibles (utilizar un framework o programar con PHP puro), nos decantamos por el uso de CodeIgniter, por las siguientes razones:

Razones para el uso de un marco de trabajo (framework) frente a desarrollar la aplicación desde cero con PHP:

  1. La seguridad debía ser un factor clave: datos introducidos por el usuario debidamente validados y filtrados para evitar ataques XSS.
  2. Comunicación con Base de Datos (MySQL) automatizada, validando todas las consultas y filtrando los datos variables para evitar inyección SQL.
  3. Disponer de componentes plenamente probados, con el objetivo de mejorar la productividad.

Razones para el uso de CodeIgniter frente a otros marcos de trabajo:

  1. Amplia documentación disponible.
  2. Ligero, y sin instalación (para comenzar a desarrollar una aplicación basta con copiar los archivos, y ponerse a trabajar).
  3. Compatibilidad con una amplia variedad de servidores y configuraciones (la aplicación se concebiría para ejecutarse en un hosting compartido con otros clientes, y con relativamente poca posibilidad de configuración).
  4. Flexibilidad, ya que no obliga a tener una determinada estructura de tablas, nombres de campos, ni adherirse a una forma de programar concreta.

Entre las desventajas y dificultades con las que nos encontramos durante el desarrollo del proyecto están:

  • Curva de aprendizaje: necesidad de aprender nuevas funciones, estructuras y métodos de programación.
  • Dificultad para adaptar el código escrito en PHP tradicional (nuestra empresa contaba con una administración escrita en PHP puro, con listados, formularios, subida de archivos, etc.). No disponíamos de tiempo para comenzar de cero, por lo que se optó por adaptar el existente a la nueva filosofía. Esto no debería representar mucha dificultad para un programador avanzado, con experiencia en desarrollo de proyectos de complejidad media.

A medida que avanza el desarrollo de la aplicación (aún está en fase de desarrollo) hemos solventado todas estas dificultades, resultando un proyecto muy interesante, de gran calidad y fácilmente reutilizable. La adaptación de los componentes ya desarrollados no conllevó serios problemas (eso sí, manual de CodeIgniter en mano) y el resultado está siendo más que satisfactorio.

No obstante, al ser este el primer proyecto serio en el que empleamos CodeIgniter no podemos hacer una valoración de la facilidad o dificultad de las futuras modificaciones. No obstante, por la forma de estructurar la aplicación y los archivos suponemos no entrañará mayor dificultad.

Proyecto con CodeIgniter

Proyecto con CodeIgniter

‘Hola Mundo’ con CodeIgniter

Saludos a todos! Primero que nada les presento esto blog creado para reunir a toda la gente que programa utilizando CodeIgniter. Pues la idea nació por parte de un amigo Ivan Argulo y mía también.

Buscamos expander esta comunidad de desarrolladores que utilicen CodeIgniter. Pues se les hace la invitación para que puedan colaborar con sus comentarios y si desean “postear” algo también, pues son bienvenidos.

Sin más que decir, aquí les tengo mi primera entrada personal, en la cual mostraré como realizar el famoso ‘Hola Mundo’ con CodeIgniter.

Bien, comencemos!

Lo que necesitamos para que funcione es descargar el CodeIgniter,un framework bastante ligero en peso, pero poderoso en acción.

Bien, no es necesario por ahora configurar ningun archivo que posea el framework, sólo que despues de haber descargado el archivo comprimido, pues, extraer su contenido en la carpeta ‘www’ desde donde levantan nuestras aplicaciones en PHP.

Si ya tenemos todo el contenido extraído en la carpeta ‘www\’, entonces si abrimos nuestro navegador y accedemos a nuestro ‘localhost’ escribiendo la dirección correcta; en mi caso tengo mi framework en ‘www\codeigniter\’ así que pondré en mi url: ‘http://localhost/codeigniter/&#8217;.

Si me siguieron hasta aquí deben haber obtenido éste resultado:

Pero vemos que si escribimos lo siguiente: ‘http://localhost/codeigniter/index.php&#8217;, obtenemos lo mismo. Esto se debe a que el CodeIgniter trabaja con este archivo que por defecto carga y trabaja como un ruteador e intercepta la solicitud realizada. Y ahora nos preguntamos, porque carga esa página de bienvenida. Pues bien, el index.php lo que hace es cargar un controlador, el cual especificamos en la misma url algo como esto: ‘http://localhost/codeigniter/index.php/welcome‘. En este caso, esa palabra: ‘welcome’ es el archivo donde se encuentra todo lo q nos esta mostrando, algo así.

Y es que la url del CodeIgniter trabaja de la siguiente manera: luego del ‘index.php’ viene el nombre del controlador\función\parámetro‘, y si al escribir ‘http://localhost/codeigniter/index.php&#8217;, carga ‘welcome.php’ es porque el CodeIgniter esta configurado por defecto para que cargue el controlador: ‘welcome.php‘, algo que es muy sencillo de modificar, pero que veremos en próximas publicaciones de este blog.

Bueno, ahora sí a lo nuestro; nuestra aplicacion: hola mundo.

Comencemos creando un nuevo archivo, en mi caso lo llamare: ‘saludo.php ‘ y le guardare en ‘www\codeigniter\system\application\controllers\’

Bien, en dicho archivo solo necesitamos escribir lo siguiente:

< ?PHP
class saludo extends Controller
{
	function index()
	{
		echo 'Hola mundo!';
	}
}
?>

Listo, ahora vamos a nuestro navegador y digitamos la url, que en mi caso es: ‘http://localhost/codeigniter/index.php/saludo&#8217;
Para explicar brevemente nuestra URL diremos que ‘codeigniter’ es la carpeta en la cual tenemos alojado nuestra aplicacion.

Lo de ‘index.php’ ya lo explicamos anteriormente. Finalmente, vemos la palabra ‘saludo’, la cual hace referencia a mi controlador saludo, el cual posee una clase llamada: ‘Saludo’, que deben tener todos los ‘controladores’ y siempre empieza con letra mayúscula, pues es así como CodeIgniter maneja la sintaxis. Este controlador debe heredar las funciones de los controladores (extends Controller). Dentro encontramos la funcion index la cual cargará por defecto. Lo que se encuentra dentro , es conocido. =)

En fin, el resultado debería ser el siguiente:

Con ésto, intento ayudarles un poco en aprender a dominar el CodeIgniter. Cualquier sugerencia, corrección, etc. pues déjennos sus comentarios.

Eso es todo, gracias! =)

Modelo Vista Controlador

Es inevitable comenzar una discusión entre programadores cuando se habla de lenguajes de programación. Ya no sólo que cada uno tiene sus preferencias personales, costumbres e ideas; finalmente se termina discutiendo acerca de Programación Web y Programación de Escritorio.

Como es lógico, cada uno tiene sus ventajas e inconvenientes. No obstante, la programación de escritorio siempre ha sido más “tradicional”. Programación por un lado, diseño de interfaz por otro…

Al analizar los lenguajes de programación web nos damos cuenta que, desde el mismo comienzo, las cosas son distintas. ¿Por qué?

De forma sencilla: el resultado tiene que ser HTML (hablando de forma general). Sin embargo, HTML no es un lenguaje de programación propiamente dicho, y los servidores no entienden HTML.

Debido a lo mencionado anteriormente, se hace necesario utilizar un lenguaje que sí entienda el servidor (léase ASP, JSP, PHP, Perl, Ruby, y un larguísimo etcétera). Esto conlleva una serie de inconvenientes, como la necesidad de aprender varios lenguajes de programación para conseguir un resultado (HTML + Lenguaje de servidor + JavaScript, habitualmente) o la imposibilidad de depurar de forma eficiente la aplicación, salvo probando el resultado (o la salida) de la misma.

Sin embargo, posiblemente el peor de todos esos inconvenientes es la excesiva tendencia a mezclar HTML con lenguaje de servidor.

Es decir, con muchísima frecuencia se ve esto (ejemplo en ASP):
<% while not rs.Eof %>
<tr>
<td>Nombre:</td>
<td><%= rs("Nombre") %></td>
</tr>
<% wend %>

Y es un serio problema… especialmente cuando quieres cambiar el diseño (en aplicaciones que deben ser reutilizadas frecuentemente), o cuando el diseñador/maquetador no conoce el lenguaje de programación utilizado.

¿Cómo solucionar, o al menos evitar en parte, este problema?

Bueno, cabe decir que es completamente imposible aislar por completo la presentación de la programación, por el simple hecho de que la presentación debe generarse desde el servidor.

Aunque hay soluciones como usar plantillas (la lógica no se crea mediante un lenguaje de programación, sino un “pseudolenguaje” de plantillas, lo que a fin de cuentas viene a ser lo mismo), actualmente se tiende a utilizar un sistema que aisla en diferentes capas la programación y el diseño: el Model Vista Controlador.

¿En qué consiste esta filosofía, denominada comúnmente MVC?

Pues bien, básicamente hay tres capas en la aplicación:

  • Modelo: capa que realiza todas las tareas de comunicación con la base de datos, como ejecución de consultas, generación de recordsets y tablas, etc.
  • Controlador: recibe las peticiones y decide qué se mostrará y cuándo. Si tenemos un área de “Productos” y otra de “Servicios”, cada una de ellas tendrá su controlador. Puede existir que un controlador rija todas las operaciones (por ejemplo “productos/ver”, “productos/listado”, “productos/borrar”).
  • Vista: al recibir la petición del controlador decide cómo se mostrará la información suministrada por el controlador. Es decir: la presentación del contenido.

¿Qué ventajas presenta este modelo?

Pues bien, al separar la presentación de la programación (o lógica de negocio), la aplicación es más fácil de modificar en el futuro (si intentas vender esto a tus superiores deberás decir que “la aplicación es más escalable” y “puede mantenerse mejor”); el resultado es más claro, y el reparto de tareas dentro del equipo de trabajo es más fácil; la depuración de la aplicación es más sencilla y, finalmente, puede utilizarse un marco de trabajo (o framework) bien testeado.

¿Presenta inconvenientes, o es todo tan bonito como dices?

Si decides utilizar un framework, evalúalo muy bien antes de comenzar, ya que su complejidad puede afectar (positiva o negativamente) al tiempo de desarrollo del proyecto.

Es necesario invertir tiempo en crear un modelo (si decides programarlo tú mismo) o leer la documentación y comprender lo que ya está hecho (si decides utilizar un framework ya creado).

No obstante, el mayor inconveniente puede ser el cambio de mentalidad de los distintos componentes del equipo, ya que se abandona la técnica tradicional de programación “pagina A -> pagina B -> pagina C”; muchos serán reacios a cambiar su forma de trabajar y posiblemente tendrán de su lado a los directivos, que no suelen querer “arriesgar” o “innovar” (salvo algunas afortunadas excepciones).

En resumen:

  • El Modelo Vista Controlador (MVC) separa la lógica de la aplicación y la presentación en varias capas.
  • Facilita la labor de todo el equipo: diseñadores gráficos, programadores, diseñadores de base de datos y.
  • Existen marcos de trabajo ya programados (según en lenguaje de programación hay más o menos posibilidades) que facilitarán el trabajo de los miembros del equipo de trabajo.