Dado que por defecto ésto no funciona, tenemos que hacer algunos pequeños ajustes.

Lo primero será crear un archivo .htaccess con lo siguiente.

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

A partir de ahora, en lugar de usar:

http://www.dominio.com.ar/index.php/controlador/accion/

Vamos a poder usar:

http://www.dominio.com.ar/controlador/accion/

Para que la impresión de urls resulte correcta, es necesario hacer un ajuste en el archivo de configuración. Esto aplica en particular si vamos a usar la función site_url del helper Url.

Para evitar que al llamar a la función nos devuelva http://www.dominio.com.ar/index.php, vamos a cambiar la línea 23 de /system/application/config/config.php, y vamos a dejar el valor de la key index_page en blanco.

La configuración debería quedar de ésta forma:

$config['index_page'] = "";

Con estos pequeños ajustes ya deberíamos estar aplicando urls semánticas sin problemas.

A lo mejor te interese leer

• Primeros pasos con CodeIgniter
• Creando un nuevo controller en CodeIgniter
• Iniciar un proyecto con CodeIgniter
• Cómo crear una clase para el Shell en Magento
• Collabtive-CI 0.6.5.2

A manera de ejercicio vamos a ir armando, a lo largo de varios posts, una pequeña y sencilla aplicación que nos obligue a loguearnos para que luego podamos realizar alguna tarea (sobre la marcha veremos qué se puede armar).

Siguiendo ésta línea, vamos a crear un controlador que nos obligará a loguearnos. De ésta forma, se convertirá en el controlador por defecto de la aplicación.

Cuando comenzamos a jugar o trabajar con el framework, vamos a ver que nos aparece un mensaje de bienvenida. Justamente, es el controlador Welcome el que se hace presente.

Ahora bien, por qué ese controlador y no otro. Esto se debe a que una de las configuraciones de CodeIgniter nos permite especificar cuál controlador se ejecutará por defecto.

Para saber cuál es o para cambiarlo, debemos acceder al archivo /system/application/config/routes.php y buscar los siguientes valores (serán los únicos no comentados):

$route['default_controller'] = "welcome";
$route['scaffolding_trigger'] = "";

Vamos a cambiar el valor de default_controller a login. Debe quedarnos de la siguiente forma.

$route['default_controller'] = "login";
$route['scaffolding_trigger'] = "";

Entendido esto, creamos nuestro primer controlador. En la carpeta /system/application/controllers tenemos el archivo welcome.php. Ese es el controlador (el único) que vamos a encontrar.

Hacemos una copia y vamos a llamar al archivo login.php. Al abrir el archivo tendremos el siguiente código.

class Welcome extends Controller {
 
    function Welcome() {
        parent::Controller();
    }
 
    function index() {
        $this->load->view('welcome_message');
    }
 
}

Lo primero que tenemos que hacer es cambiar el nombre de la clase.

Si prestan atención, dado que el framework es compatible con las versiones 4 y 5 de Php, todas las clases que veremos vienen programadas para Php 4. Esto no quita que nosotros podamos continuar nuestro desarrollo armando nuestras clases en Php 5.

Dicho ésto, nuestro controller Login lo haremos de esa forma, así que el cambio no será sólo de nombre, sino que declararemos los métodos como públicos y modificaremos el constructor de la clase.

El resultado debería quedarnos de la siguiente forma.

class Login extends Controller {
 
    public function __construct() {
        parent::Controller();
    }
 
    public function index() {
        $this->load->view('welcome_message');
    }
 
}

Si bien el controller ya funcionaría, todavía nos faltan algunos detalles para darnos cuenta, efectivamente, que el controlador que va a ejecutarse es el nuestro.

Dentro del método index(), podemos ver que se invoca a la vista welcome_message. Esa vista puede encontrarse en /system/application/views/welcome_message.php. De más está decir que el nombre de la vista se corresponde con el nombre del archivo (sin la extensión).

Siguiendo nuestro primer experimento, vamos a duplicar también ese archivo y vamos a llamarlo login.php. A éste archivo pueden hacerle las modificaciones que consideren necesarias. Ahora tenemos que indicarle al controlador que en lugar de utilizar la vista welcome_message, utilize la nuestra.

El código final nos quedaría de la siguiente forma.

class Login extends Controller {
 
    public function __construct() {
        parent::Controller();
    }
 
    public function index() {
        $this->load->view('login');
    }
 
}

Y si refrescamos nuestro navegador, veríamos algo similar a ésta pantalla (dependiendo de lo que hayan cambiado en la vista) .

Como ven, resulta bastante sencillo dar los primeros pasos.

A lo mejor te interese leer

• Url friendly en CodeIgniter
• Primeros pasos con CodeIgniter
• Iniciar un proyecto con CodeIgniter
• Cómo crear una clase para el Shell en Magento
• Collabtive-CI 0.6.5.2

Una vez que hayas descomprimido el framework, ya estamos listos para empezar.
Lo primero que deberíamos hacer es comenzar con las configuraciones básicas. Para esto vamos a abrir el archivo /system/application/config/config.php y vamos a cambiar el primer parámetro en la línea 14:

$config['base_url'] = "http://example.com/";

Lo vamos a cambiar por la url completa de nuestra aplicación.
Vamos a suponer que se tratara de este mismo blog, la url quedaría de la siguiente forma.

$config['base_url'] = "http://www.damianculotta.com.ar/";

Como bien dice el manual, si vamos a utilizar base de datos, debemos especificar la configuración en /system/application/config/database.php. Busquemos la siguiente sección:

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "";
$db['default']['password'] = "";
$db['default']['database'] = "";
$db['default']['dbdriver'] = "mysql";
$db['default']['dbprefix'] = "";
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = TRUE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = "";
$db['default']['char_set'] = "utf8";
$db['default']['dbcollat'] = "utf8_general_ci";

Y completemos, al menos, los datos de conexión a nuestra base de datos.

Cuando accedamos a nuestra url, veremos el mensaje de bienvenida que es manejado por el controller Welcome del framework.

Con esto ya estamos listos para comenzar a desarrollar nuestra primera aplicación.

A lo mejor te interese leer

• Url friendly en CodeIgniter
• Creando un nuevo controller en CodeIgniter
• Iniciar un proyecto con CodeIgniter
• Cómo crear una clase para el Shell en Magento
• Collabtive-CI 0.6.5.2

Este post no trata sobre vender las bondades del framework, sino sobre cómo empezar a usarlo.

Inicializar un proyecto es algo bastante sencillo y rápido.

Lo primero será descargar CodeIgniter.

Una vez descomprimido el paquete (y suponiendo que lo ubicamos en el directorio del proyecto) nos vamos a encontrar con la siguiente estructura.

/
|
+--/ system
|
+--/ user_guide
|
+-- index.php
|
+-- license.txt

Ahora, si apuntamos con nuestro navegador hacia la dirección/carpeta en donde esté el proyecto, tendríamos que ver la siguiente página.

Esto quiere decir que vamos bien, pero en realidad no hemos hecho nada hasta ahora.

Dentro de la carpeta system vamos a encontrar unas cuantas subcarpetas que son las que conforman el framework, pero a nosotros nos importará el contenido de application.

/
|
+--/ system
   |
   +--/ application
      |
      +--/ config
      |
      +--/ controllers
      |
      +--/ errors
      |
      +--/ helpers
      |
      +--/ hooks
      |
      +--/ language
      |
      +--/ libraries
      |
      +--/ models
      |
      +--/ views
      |
      +-- index.html

Es con ésta estructura con la que vamos a trabajar para darle forma a nuestro desarrollo. Aunque primero, debemos entender por y para qué ésta estructura y dónde debemos meter mano para comenzar.

En el directorio config, por más obvio que resulte, encontraremos varios archivos de configuración que nos permitirían establecer una serie de parámetros para la aplicación que van desde url, logs, cache, base de datos hasta tablas de ruteo y controlador por defecto.

El directorio controllers tiene (seguimos con las obviedades) los controladores de la aplicación, que serán quienes se encarguen de manejar la peticiones del usuario y realizar las acciones pertinentes.

Dentro de errors podemos dejar nuestras páginas de error personalizadas.

En helpers irán funciones que nos ayudarán a resolver alguna funcionalidad o a complementar algún proceso. Los helpers en CodeIgniter son funciones procedurales.

CI soporta la implementación de diferentes idiomas, por lo cual, cada archivo de idioma qeu fuéramos a utilizar, debería guardarse en el directorio language.

El objetivo de libraries es ordenar clases que necesitemos para extender funcionalidad del framework, agregar nuevas, o incluso sobreescribir clases existentes.

Los models son los encargados de interactuar con nuestra base de datos. (Con ésta brevísima explicación no busco desarrollar el concepto de modelos del MVC, sino dar una idea de cómo estructurar la aplicación).

Finalmente, el directorio views contendrá las vistas que serán invocadas desde los diferentes controladores.

A partir de ahora, con la documentación de CodeIgniter a mano, tendremos que empezar a tocar las configuraciones y crear nuestros primeros controladores.

A lo mejor te interese leer

• Url friendly en CodeIgniter
• Creando un nuevo controller en CodeIgniter
• Primeros pasos con CodeIgniter
• Cómo crear una clase para el Shell en Magento
• Collabtive-CI 0.6.5.2

Para definir una constante, basta con la siguiente línea:

<?php
define("CONSTANTE", "Hola mundo.");
?>

Una vez definida, simplemente debemos invocarla para hacer uso de ese valor.

<?php
echo CONSTANTE;
//El resultado en pantalla será "Hola mundo."
?>

Normalmente, damos por sentado que dichas constantes están definidas, pero, ¿y si por algún motivo una constante no se definió?.

Si hacemos uso de esa constante y se diera ése último caso, lo más probable es que el resultado que obtengamos no sea el esperado.

Para controlar si la constante está declara, basta con hacer la siguiente pregunta.

<?php
if (defined('CONSTANTE')) {
    echo CONSTANTE;
} else {
    echo "La constante no ha sido definida";
}
?>

Un tip bastante sencillo, para algunos hasta obvio, pero de seguro útil.

A lo mejor te interese leer

• Cómo crear una clase para el Shell en Magento
• Provincias en un formulario de contacto personalizado en Magento
• Accediendo a configuraciones de Magento
• Opciones de formatDate en Magento
• Cambiar formato a un valor de tipo Fecha en Magento

Esto lo vamos a lograr gracias a FirePHP, que funciona integrándose sobre Firebug, y se compone de dos elementos:

• Extensión para Firefox de FirePHP.
• Librería Php.

Una vez que hayas instalado la extensión, bajamos la librería (con soporte para Php 4 y 5) y la incluimos en nuestro proyecto.

A continuación un ejemplo muy sencillo para demostrar los efectos de su uso.

<?php
//Incluímos la librería para Php 5
require_once('FirePHPCore/FirePHP.class.php');
 
//Instanciamos el objeto
$firephp = FirePHP::getInstance(true);
 
//Definición de la variable que vamos a probar
$variable = array('i'=>10, 'j'=>20);
 
//Invocamos los distintos métodos disponibles
$firephp->log($variable, 'Resultado de $variable');
$firephp->info($variable, 'Resultado de $variable');
$firephp->warn($variable, 'Resultado de $variable');
$firephp->error($variable, 'Resultado de $variable');
?>

Si ejecutamos éste código en nuestro navegador (con la extensión habilitada), tendríamos que ver algo como lo siguiente.

De ésta forma sumamos una nueva herramienta para controlar nuestro trabajo diario.

A lo mejor te interese leer

• Debuggeando Javascript con Firebug
• Debuggear variables dentro de Magento
• Cómo crear una clase para el Shell en Magento
• Collabtive-CI 0.6.5.2
• Collabtive-CI 0.6.5.1

Otra ventaja de ésta técnica, es que podemos forzar las descargas para que se realizen desde nuestra página.

Lo que vamos a hacer, es generar un archivo de descarga que, dependiendo de algún parámetro que pueda llegarle, va a leer el contenido de un archivo, y ese contenido, será impreso en nuestro archivo de descarga.

De ésta forma, la ubicación real del archivo nunca será expuesta.

El ejemplo:

<?php
$archivo = "documento.pdf";
$carpeta = "descargas/";
header("content-disposition: attachment; filename=" . $archivo);
header("content-type: application/octet-stream");
header("content-length: " . filesize($carpeta . $archivo));
header("pragma: no-cache");
header("expires: 0");
$lectura = fopen($carpeta . $archivo,"r");
echo fread($lectura,filesize($carpeta . $archivo));
fclose($lectura);
exit();
?>

Lo que nos va a interesar modificar, es el valor de las varaibles $archivo y $carpeta.

Según cada caso, puede llegar el nombre del archivo mediante un $_POST o un $_GET; o en lugar del nombre, algún id que a través de alguna consulta a base de datos, nos de el nombre del archivo a descargar.

Las posibilidades son tantas como escenarios enfrentemos.

A lo mejor te interese leer

• Cómo crear una clase para el Shell en Magento
• Collabtive-CI 0.6.5.2
• Collabtive-CI 0.6.5.1
• Extendiendo la configuración gráfica del cron en Magento
• Configuración gráfica para un cron job en Magento

Existen otros casos, en los cuales llegamos con la arquitectura ya definida, pero la documentación se encarga de tapar esos baches con los cuales uno se topa.

El otro escenario posible, es la razón de ser de éste post.

Supongamos que estamos ante una aplicación en la cuál no tuvimos nada que ver con su arquitectura, y para rematarla, no tenemos documentación que pueda consultarse.

Si a esto le sumamos algunas cuestiones relacionadas con la complejidad del codigo y el grado de abstracción que pueda presentar, se nos pueden complicar un poco las tareas diarias.

En mi caso, la aplicación que se ajusta a éste último esquema, es Magento.

Para los que ya han visto algo del código de ésta aplicación, en particular la capa de plantillas que utiliza, entenderán mejor hacia dónde apunto con conocer el contexto de un objeto.

Cada vez que abrimos uno de los bloques de plantillas, solemos encontrarnos con algo como esto.

echo $this->getFormAction();

La primer pregunta que uno se hace es: ¿quién es $this?.

Bien, para sabér de qué clase se trata, vamos a usar una función Php para saber con quién estamos lidiando.

Voy a tomar como ejemplo, el formulario de contacto de Magento. Abrimos el archivo form.phtml, y vamos a argegar lo siguiente antes de la apertura del formulario.

print_r(get_class($this));

La función get_class, nos devuelve el nombre de la clase instanciada. En este caso, se trata de la clase Mage_Core_Block_Template.

Lo segundo que podemos probar para ubicarnos mejor, es buscar las clases de las que hereda nuestro actual objeto.

Para eso, volvemos a recurrir a otra función nativa, llamada class_parents.

En la plantilla del formulario, lo aplicaríamos de la siguiente forma.

print_r(class_parents($this));

El resultado de ésta llamada nos devuelve un array con las clases de las cuales hereda nuestro objeto.

Array
(
    [Mage_Core_Block_Abstract] => Mage_Core_Block_Abstract
    [Varien_Object] => Varien_Object
)

Como pueden ver, con el uso de estas dos funciones, se nos simplifica significativamente conocer el contexto de un objeto.

A lo mejor te interese leer

• Cómo crear una clase para el Shell en Magento
• Provincias en un formulario de contacto personalizado en Magento
• Accediendo a configuraciones de Magento
• Opciones de formatDate en Magento
• Cambiar formato a un valor de tipo Fecha en Magento