¿Pero sabías que se pueden crear tipos de posts personalizados en los que alojar cualquier tipo de dato que se te ocurra?

Me explico: Por defecto WordPress trae cuatro tipos de posts distintos:

1. Entradas – Es el tipo predeterminado, para alojar nuevas entradas tipo blog.
2. Páginas – Las páginas permanentes, fuera de la estructura cronológica de los posts.
3. Adjuntos- Corresponde a la página que hay disponible para cada fichero adjunto.
4. Revisiones – Una revisión es una versión antigua de otro documento, o un borrador.
5. Menús – Son los menús de navegación creados desde el panel de control de WordPress. Sí, también es un tipo de post. ¿Sorprendido?

Todos ellos los crea WordPress automáticamente. Pero además de esos, nos permite crear otros nuevos que se adapten mejor a nuestras necesidades. La magia la lleva a cabo la función register_post_type().

Vamos a realizar un ejemplo en el que crearemos un catálogo de discos duros. Cada disco duro tendrá una serie de campos:

• Nombre
• Descripción
• Fabricante
• Precio
• Capacidad
• Velocidad de rotación
• Imagen

Paso 1 – Dar de alta el nuevo tipo de post

Lo primero será crear el nuevo tipo de post. Podremos hacerlo de dos formas: o bien mediante código PHP, o bien desde el panel de control de WordPress.

Método 1 – Con código

Añadimos este código al fichero functions.php de nuestra plantilla:

    // Registramos un nuevo tipo de post discos duros
    add_action('init', 'register_dd', 1);
    function register_dd() {
        $labels = array(
            'name' => _x('Discos duros', 'post type general name'),
            'singular_name' => _x('Disco duro', 'post type singular name'),
            'add_new' => _x('Añadir nuevo', 'Disco duro'),
            'add_new_item' => __('Añadir nuevo disco duro'),
            'edit_item' => __('Editar disco duro'),
            'new_item' => __('Nuevo disco duro'),
            'view_item' => __('Ver disco duro'),
            'search_items' => __('Buscar discos duros'),
            'not_found' =>  __('No se ha encontrado nada'),
            'not_found_in_trash' => __('No se ha encontrado nada en la papelera'),
        );
        $args = array(
            'labels' => $labels,
            'public' => true,
            'hierarchical' => false,
            'menu_position' => 5,
            'has_archive' => true,
            'query_var' => true
            'supports' => array('title','editor','thumbnail'),
            'rewrite' => array('slug' => 'disco-duro'),
        );

        register_post_type( 'disco-duro', $args );
    }

Paso a paso, esto es lo que hacemos:

1. Enganchamos la función “register_dd()” al evento “init”, dándole alta prioridad (cuanto más bajo, más prioritario).
2. Definimos la función register_dd():
1. Creamos un array $labels con todas las etiquetas que acompañarán al panel de control de este nuevo tipo de post.
2. Creamos otro array con todas las opciones:
1. labels – Por un lado, asignamos las etiquetas.
2. public – Le damos visibilidad pública.
3. hierarchical – No es un tipo de post jerárquico, donde pueda tener un post padre.
4. menu_position – Introduciendo 5 hacemos que se muestre bajo el menú de entradas.
5. has_archive – Permitimos acceder al archivo (listado) de discos duros.
6. query_var – Indicamos que se podrán hacer consultas atacando a este tipo de post.
7. supports – Lista de las funcionalidades que hemos decidido que tenga soporte este tipo de post. En concreto, permitos que tenga un título, una descripción con su editor WYSIWYG, y una imagen de miniatura.
8. rewrite – Indicamos el nombre base que tendrán las URLs amigables.
3. Finalmente, damos de alta el tipo de post, al que llamamos ‘discoduro’.

Si ahora accedemos al panel de control, esto es lo que veremos:

¡Ya tenemos nuestro tipo de post creado! Ha sido fácil, ¿verdad?

Método 2 – Sin código

¿Dije que la comunidad de desarrolladores de WordPress es genial? Existe un plugin que permite hacer todo eso, pero a golpe de ratón. Os presento a More Types. Mediante formularios web podremos crear y ajustar tanto como queramos nuestros tipos de posts personalizados. Instálatelo y ve a Ajustes > More Types:

Como ves, aparecen tanto los tipos por defecto, como los definidos por el usuario. Vamos a crear un nuevo tipo definido por el usuario pulsando sobre “Add new Post Type”. Completamos los siguientes campos:

• Post type name singular: Disco duro.
• Post type name plural: Discos duros.
• Features: Marcamos ‘Título’, ‘Editor’ y ‘Miniatura’.

• Has archive: Yes.
• Menu position: 5.
• Menu name: Discos duros.
• ‘Add new’ text: Añadir nuevo.
• ‘Add new item’ text: Añadir nuevo disco duro.
• ‘Edit item’ text: Editar disco duro.
• ‘New item’ text: Nuevo disco duro.
• ‘View item’ text: Ver disco duro.
• ‘Search item’ text: Buscar disco duro.
• ‘Not found’ text: No se ha encontrado nada.
• ‘Not found in Trash’ text: No se ha encontrado nada en la papelera.

Pulsamos sobre ‘Save’ y ya lo tenemos. El resultado es el mismo que en el método 1:

Paso 2 – Taxonomías

La Wikipedia define a la taxonomía como la ciencia de la clasificación; es decir, una forma de agrupar cosas. Lo has usado ya mucho: cada vez que creas una categoría en tus artículos o cuando introduces las etiquetas. Tal como ocurría con los tipos de posts, WordPress trae tres taxonomías creadas de forma predeterminada:

1. Categorías – Las categorías que ya has usado para clasificar tus artículos.
2. Etiquetas – Etiquetas (palabras clave) que añades a cada artículo.
3. Categoría de enlace – Las categorías con las que clasificas los enlaces en WordPress.

¿Qué taxonomías podemos crear para clasificar los discos duros? Pues unas cuantas Pero en este ejemplo vamos a crear sólo una: fabricante. Y de nuevo, tal como sucedía al crear los tipos de posts, podemos crearlo o bien con código, o bien utilizando plugins de terceros sin código.

Método 1 – Con código

Podemos crearla mediante código utilizando la función register_taxonomy():

    // Y creamos un nueva taxonomía para el nuevo tipo de post
    add_action('init', 'register_df', 1);
    function register_df() {
        $labels = array(
            'name' => _x( 'Fabricantes', 'taxonomy general name' ),
            'singular_name' => _x( 'fabricante', 'taxonomy singular name' ),
            'search_items' =>  __( 'Buscar fabricantes' ),
            'popular_items' => __( 'Fabricantes' ),
            'all_items' => __( 'Todos' ),
            'edit_item' => __( 'Editar fabricante' ),
            'update_item' => __( 'Actualizar fabricante' ),
            'add_new_item' => __( 'Añadir nuevo fabricante' ),
            'new_item_name' => __( 'Nuevo nombre de fabricante' ),
            'separate_items_with_commas' => __( 'Separar fabricantes con comas' ),
            'add_or_remove_items' => __( 'Añadir o borrar fabricantes' ),
            'choose_from_most_used' => __( 'Elegir de entre los fabricantes más populares' )
        );
        $args = array(
            'hierarchical' => true,
            'public' => true,
            'labels' => $labels,
            'show_ui' => true,
            'rewrite' => array( 'slug' => 'fabricantes' ),
            'query_var' => true,
		);

        register_taxonomy('fabricantes', 'discosduros', $args);
    }

Viéndolo paso a paso:

1. Atamos la función ‘register_df’()’ al evento ‘init’, de nuevo con alta prioridad.
2. Definimos la función register_df():
1. Creamos un array $labels con todas las etiquetas que acompañarán al panel de control de este nuevo tipo de taxonomía.
2. Creamos otro array con todas las opciones:
1. hierarchical – Es un tipo de taxonomía jerárquica. Por ejemplo, las categorías son jerárquicas, mientras que las etiquetas no lo son.
2. public – Le damos visibilidad pública.
3. labels – Por un lado, asignamos las etiquetas.
4. show_ui – Indicamos que se mostrará la interfaz de usuario en el panel de control para gestionarlas.
5. rewrite – Nos permite redefinir la estructura de las URLs dinámicas con las que se accede a cada fabricante.
6. query_var – Permite realizar consultas SQL atacando a esta taxonomía.
3. Finalmente, damos de alta el tipo de taxonomía, a la que llamamos ‘fabricantes’, y la vinculamos al tipo de post ‘discosduros’.

¿Qué cambio ha supuesto esto? En resumen, tenemos dos. Por un lado, nos aparecerá una nueva cajita en la página de añadir/editar disco duro, donde podremos establecer el fabricante:

Y por otro, tenemos un nuevo apartado en la columna izquierda desde donde podremos gestionar los fabricantes:

Espera, ¿dije que la comunidad de desarrolladores de WordPress es genial? También existe un plugin que nos permita crear taxonomías desde el panel de control. En esta ocasión os presento a More Taxonomies (ojo, está en estado beta). Mediante formularios web podremos crear y ajustar tanto como queramos nuestros tipos de taxonomías personalizadas. Instálatelo y ve a Ajustes > More Taxonomies:

Como ves, al pie aparecen tanto las taxonomías por defecto, como las definidos por el usuario. Vamos a crear una nueva taxonomía definida por el usuario pulsando sobre “Add new Taxonomie”. Completamos los siguientes campos:

• Taxonomy name singular: Disco duro.
• Taxonomy name plural: Discos duros.
• Hierarchical: Yes
• Allow permalinks: Yes
• Taxonomy slug: fabricante
• Show tag cloud: No
• Available to: Discos duro

Paso 3 – Añadir nuevos campos

function change_columns( $cols ) {
  $cols = array(
    'cb'            => '<input type="checkbox" />',
    'title'         => __( 'Nombre', 'trans'),
    'manufacturer'  => __( 'Fabricante',      'trans' ),
    'size'          => __( 'Capacidad', 'trans' ),
    'price'         => __( 'Precio', 'trans' ),
  );
  return $cols;
}
add_filter( "manage_disco-duro_posts_columns", "change_columns" );

// Definir contenido de las columnas no estándar
function custom_columns( $column, $post_id ) {
  switch ( $column ) {
    case "manufacturer":
      $manufacturers = get_the_terms($post_id, 'fabricante');
      foreach($manufacturers as $item) {
        echo '<a href="/'.$item->taxonomy."/".$item->slug.'">'.$item->name."</a>";
        break;
      }
      break;
    case "size":
      echo get_post_meta( $post_id, 'size', true)." GB";
      break;
    case "price":
      echo get_post_meta( $post_id, 'price', true)." €";
      break;
  }
}
add_action( "manage_disco-duro_posts_custom_column", "custom_columns", 10, 2 );

function sortable_columns() {
  return array(
    'title' => 'title',
    'manufacturer'      => 'manufacturer',
    'size' => 'size',
    'price'     => 'price'
  );
}
add_filter( "manage_edit-disco-duro_sortable_columns", "sortable_columns" );

function taxonomy_filter_restrict_manage_posts() {
    global $typenow;

    if ( $typenow == 'disco-duro' ) {
    	$filters = get_object_taxonomies( $typenow );

        foreach ( $filters as $tax_slug ) {
            $tax_obj = get_taxonomy( $tax_slug );
            wp_dropdown_categories( array(
                'show_option_all' => __('Mostrar todos los '.$tax_obj->label ),
                'taxonomy' 	  => $tax_slug,
                'name' 		  => $tax_obj->name,
                'orderby' 	  => 'name',
                'selected' 	  => $_GET[$tax_slug],
                'hierarchical' 	  => $tax_obj->hierarchical,
                'show_count' 	  => false,
                'hide_empty' 	  => true
            ) );
        }
    }
}
add_action( 'restrict_manage_posts', 'taxonomy_filter_restrict_manage_posts' );

function taxonomy_filter_post_type_request( $query ) {
  global $pagenow, $typenow;

  if ( 'edit.php' == $pagenow ) {
    $filters = get_object_taxonomies( $typenow );
    foreach ( $filters as $tax_slug ) {
      $var = &$query->query_vars[$tax_slug];
      if ( isset( $var ) ) {
        $term = get_term_by( 'id', $var, $tax_slug );
        $var = $term->slug;
      }
    }
  }
}
add_filter( 'parse_query', 'taxonomy_filter_post_type_request' );

<?php get_header(); ?>

<?php if ( have_posts() ) while ( have_posts() ) : the_post(); ?>
    <?php $manufacturers = get_the_terms(get_the_ID(), 'fabricante');?>
	<?php $custom = get_post_custom(); ?>
	<h1 class="entry-title"><?php the_title(); ?></h1>
    <?php
    if ( has_post_thumbnail() ) {
      the_post_thumbnail();
    }
    ?>
	<h2>Fabricante: <?php foreach($manufacturers as $item) { echo $item->name; break; } ?></h2>
    <?php the_content(); ?>
    <p>
        Precio: <?php echo $custom['price'][0]; ?>€<br />
        Capacidad: <?php echo $custom['size'][0]; ?>GB<br />
        Velocidad: <?php echo $custom['speed'][0]; ?> rpm<br />
    </p>
<?php endwhile; // end of the loop. ?>

<?php get_sidebar(); ?>
<?php get_footer(); ?>

Añadir rutas

Memorizar todos los caminos puede ser un poco complicado. Pero por suerte estos teléfonos traen GPS integrado. ¿Cómo podemos importar previamente nuestras rutas? Con Google Maps es muy sencillo. En primer lugar, definimos cómodamente la ruta en Google Earth desde nuestro PC:

Una vez definida la ruta, la guardamos a un fichero .kmz, pulsando sobre “Guardar lugar como…”

Ahora, desde Google Maps, y habiendo iniciado sesión con nuestra cuenta de Google, accedemos a “Mis mapas” > “Crear un mapa nuevo” > “Importar”, y seleccionamos el fichero .kmz. Establecemos un título y listo, ya tenemos la ruta lista para consultar en cualquier momento.

Ya desde Android, accedemos a Maps, pulsamos sobre el botón “Capas”, y desde ahí en “Más capas” > “Mis mapas”, podremos seleccionar cualquiera de nuestras rutas. ¡Y ya está! De esta forma ya no te perderás por los caminos.

Seguimientos

Existen muchas aplicaciones que realizan un seguimiento de los recorridos. Yo utilizo Endomondo, y me funciona de maravilla. De nuevo, mediante GPS, realiza un completo seguimiento del recorrido, velocidades, tiempos, realiza pausas automáticas, guarda un histórico, calorías quemadas, etc. Lo arrancas, y no es necesario que vuelvas a preocuparte hasta que finalices la ruta Por supuesto, sirve igualmente para recorridos a pie.

Destacaría de esta plataforma, respecto a otras, su facilidad de uso, la gran comunidad de usuarios que hay detrás, que es multiplataforma (Symbian, Android, iOs, Blackberry), altamente social y gratuito (pese a que existe una versión de pago por 2.95€).

Ahora que la batería de mi teléfono está cargada, me retiro. ¡Me espera una pequeña ruta de 20Km!

Edit. 10/04/2011 a las 19:48.
Soy un lila; hacía bastante viento (rachas de 45km/h), de modo que al final no he llegado a los 20Km. Pero como muestra de la utilidad de “compartir rutas” de Endomondo, aquí está mi práctica de hoy:

Y aquí las rachas de viento registradas hoy en el observatorio de Toledo:

En primer lugar, ¿qué diantres es un ORM? Viene de las siglas Object-relational mapping, que viene a traducirse como Mapeo objeto-relacional. En concreto es una técnica, o patrón arquitectónico, que permite comunicar dos sistemas distintos, típicamente una base de datos relacional con objetos de un lenguaje orientado a objetos, mediante un sistema que “mapea” (vincula) ambos sistemas. Mucha gente (yo mismo) ha creado a mano sus objetos mapeadores que, junto con objetos usando el patrón Active Record, daban un resultado muy similar a lo que un ORM nos ofrece. Pero oye, un ORM hace todo el trabajo sucio por nosotros

Existen ORMs para la mayoría de lenguajes de programación. Por ejemplo, en Java es muy popular Hibernate, en .NET se utiliza ADO.NET Entity Framework, y en PHP el más usado es Doctrine (hay más). Doctrine está inspirado en Hibernate.

Pero veamos algunas de las características que nos ofrece un ORM como Doctrine 2:

• Muy sencillo de configurar. De hecho, no es necesario mantener complejos ficheros de configuración XML.
• Tiene su propio dialecto de SQL, llamado DQL (Doctrine Query Language).
• Puede generar los modelos (las clases PHP que representan una fila de la BD) a partir de la base de datos. Sólo habría que definir las dependencias entre ellos
• Del mismo modo, también puede generar la base de datos a partir de los modelos.

¡Fantástico! Él puede crear las tablas, y las consultas por nosotros. Pero veamos ahora lo sencillo que es usarlo:

/* Código de inicialización ... */
$user = new User();
$user->name = "john";
$user->password = "doe";
$em->persist($user);
$em->flush();

Para que este código funcione sólo tenemos que hacer dos cosas:

1. Creamos el código de inicialización que cree el EntityManager $em. Es el objeto que en última instancia lleva a cabo las acciones.
2. Definimos las entidades (módulos) especificando en comentarios (o en XML o en YAML) cómo se relaciona con la base de dato

Vamos a ver cómo instalarlo y después haremos un ejemplo sencillo en SQLite.

Instalación

Si bien podemos instalarlo a mano descargándolo desde la página de Doctrine, para esta guía asumiré que se ha instalado con PEAR. Para ello tenemos primer que instalar el canal:

sudo pear channel-discover pear.doctrine-project.org

Y después instalamos el ORM:

sudo pear install pear.doctrine-project.org/DoctrineORM-2.0.1

Ahora lo tenemos instalado. Podemos probar a ejecutar su utilidad de línea de comandos, y nos mostrará esto:

$ doctrine
Doctrine Command Line Interface version 2.0.1
Usage:
[options] command [arguments]
Options:
--help           -h Display this help message.
--quiet          -q Do not output any message.
--verbose        -v Increase verbosity of messages.
--version        -V Display this program version.
--ansi           -a Force ANSI output.
--no-interaction -n Do not ask any interactive question.
Available commands:
help                         Displays help for a command (?)
list                         Lists commands
dbal
:import                      Import SQL file(s) directly to Database.
:run-sql                     Executes arbitrary SQL directly from the command line.
orm
:convert-d1-schema           Converts Doctrine 1.X schema into a Doctrine 2.X schema.
:convert-mapping             Convert mapping information between supported formats.
:ensure-production-settings  Verify that Doctrine is properly configured for a production environment.
:generate-entities           Generate entity classes and method stubs from your mapping information.
:generate-proxies            Generates proxy classes for entity classes.
:generate-repositories       Generate repository classes from your mapping information.
:run-dql                     Executes arbitrary DQL directly from the command line.
:validate-schema             Validate that the mapping files.
orm:clear-cache
:metadata                    Clear all metadata cache of the various cache drivers.
:query                       Clear all query cache of the various cache drivers.
:result                      Clear result cache of the various cache drivers.
orm:schema-tool
:create                      Processes the schema and either create it directly on EntityManager Storage Connection or generate the SQL output.
:drop                        Drop the complete database schema of EntityManager Storage Connection or generate the corresponding SQL output.
:update                      Processes the schema and either update the database schema of EntityManager Storage Connection or generate the SQL output.

Demo básica

Para este apartado, voy a utilizar una demo Sandbox (entorno de pruebas) prácticamente igual que la que usan en la documentación de Doctrine 2. En este artículo encontrarás el código de todos los ficheros necesarios. Además, al final del mismo encontrarás un enlace para poder descargarlo.

El proyecto consiste de sólo 4 ficheros:

• Entities/Users.php – Modelo de usuarios
• Entities/Address.php – Modelo de dirección
• cli-config.php – Fichero PHP que contiene el código de inicialización necesario para usar la utilidad en linea de comandos ‘doctrine’. Cada vez que usemos la utilidad ‘doctrine’, tendremos que tener este fichero.
• index.php – Código de inicialización típico de una aplicación web que utilice Doctrine 2.

Vamos a echar un vistazo a los ficheros. En primer lugar veamos cómo es el archivo cli-config.php:

<?php
// (1) Autocargamos clases
require_once 'Doctrine/Common/ClassLoader.php';
$classLoader = new \Doctrine\Common\ClassLoader('Doctrine');
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Entities', __DIR__);
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Proxies', __DIR__);
$classLoader->register();

// (2) Configuración
$config = new \Doctrine\ORM\Configuration();

// (3) Caché
$cache = new \Doctrine\Common\Cache\ArrayCache();
$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);

// (4) Driver
$driverImpl = $config->newDefaultAnnotationDriver(array(__DIR__."/Entities"));
$config->setMetadataDriverImpl($driverImpl);

// (5) Proxies
$config->setProxyDir(__DIR__ . '/Proxies');
$config->setProxyNamespace('Proxies');

// (6) Conexión
$connectionOptions = array(
'driver' => 'pdo_sqlite',
'path' => 'database.sqlite'
);

// (7) EntityManager
$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);

// (8) HelperSet
$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));

¡Que nadie se asuste! Realmente es un código muy sencillo, y prácticamente siempre se usará algo igual o muy parecido. Para superar el medio inicial, vamos a ver detalladamente qué es lo que ha pasado. El proceso de inicialización consta básicamente de dos pasos: Por una parte hay que asegurarse de que las clases de Doctrine pueden cargarse, y por otra hay que crear una instancia del Entity Manager. Siguiendo paso a paso:

1. En primer lugar autocargamos las clases necesarias (nota: para esto podríamos haber utilizado el autocargador de otro framework). En concreto autocargaremos 3 secciones:
   1. El propio Doctrine, que trae Common, DBAL, ORM y Symfony. Si lo hemos instalado con PEAR, podremos verlo en el directorio /usr/share/php/Doctrine.
   2. Entities, que es el directorio en el que almacenaremos nuestros modelos.
   3. Proxies, otro espacio que es necesario definir. Los proxies son subclases de nuestros modelos que el propio Doctrine crea automáticamente.
2. Una vez que nos hemos asegurado de que todas las clases pueden cargarse automáticamente, comenzamos a crear nuestro objeto EntityManager. Para ello, lo primero es crear un objeto de tipo Configuration.
3. El primer parámetro que vamos a configurar es la caché. Podríamos haber usado APC, el sistema de cachés de facto de PHP (aconsejable en un entorno en producción), pero para pruebas usaremos el método ArrayCache.
4. A continuación establecemos el driver con el que mapearemos nuestra base de datos. Esto es necesario para  hacer que nuestros modelos se correlacionen con nuestras bases de datos. Existen tres drivers disponibles:
   1. XML, desde donde se puede definir como encajar el modelo con la base de datos mediante sintaxis XML.
   2. YAML, al igual que con XML, también se puede definir utilizando YAML.
   3. Anotaciones, que en mi opinión son una maravilla. Mediante etiquetas en comentarios PHP defines cómo se mapean los datos. Más abajo, cuando lleguemos a los modelos, veremos un ejemplo de uso.
5. Ahora configuramos los proxies. Simplemente establecemos su directorio, y su espacio de nombres.
6. Conexión. Es aquí donde establecemos dónde se se encuentra nuestra base de datos. Si ésta no existiera, Doctrine la crearía por nosotros. En nuestro ejemplo usaremos SQLite.
7. Ya está todo listo: hemos configurado la Caché, el Driver para mapear, los proxies y la conexión. Ya podemos crear el objeto EntityManager.
8. Por último, creamos un objeto de tipo HelperSet, que es el que utilizará la utilidad de línea de comandos para saber cómo conectarse. El objeto HelperSet debe tener dos helpers: db, para identificar la conexión, y em, el EntityManager.

Ya tenemos listo el fichero cli-config.php, que como dijimos, es el que se utiliza para conectar la utilidad de consola ‘doctrine’ con nuestro proyecto.

Ahora vamos a ver los modelos.

Entities/Adress.php

<?php
namespace Entities;

/** @Entity @Table(name="addresses") */
class Address
{
   /**
    * @Id @Column(type="integer")
    * @GeneratedValue(strategy="AUTO")
    */
   private $id;

   /** @Column(type="string", length=255) */
   private $street;

   /** @OneToOne(targetEntity="User", mappedBy="address") */
   private $user;

   public function getId()
   {
      return $this->id;
   }

   public function getStreet()
   {
      return $this->street;
   }

   public function setStreet($street)
   {
      $this->street = $street;
   }

   public function getUser()
   {
      return $this->user;
   }

   public function setUser(User $user)
   {
      if ($this->user !== $user) {
         $this->user = $user;
         $user->setAddress($this);
      }
   }
}

Entities/User.php

<?php
namespace Entities;

/** @Entity @Table(name="users") */
class User
{
   /**
    * @Id @Column(type="integer")
    * @GeneratedValue(strategy="AUTO")
    */
   private $id;

   /** @Column(type="string", length=50) */
   private $name;

   /**
    * @OneToOne(targetEntity="Address", inversedBy="user")
    * @JoinColumn(name="address_id", referencedColumnName="id")
    */
   private $address;

   public function getId()
   {
      return $this->id;
   }

   public function getName()
   {
      return $this->name;
   }

   public function setName($name)
   {
      $this->name = $name;
   }

   public function getAddress()
   {
      return $this->address;
   }

   public function setAddress(Address $address)
   {
      if ($this->address !== $address) {
         $this->address = $address;
         $address->setUser($this);
      }
   }
}

No me detendré a explicar cómo se definen los modelos. En la propia documentación de Doctrine puedes ver una introducción al mapeo. Lo importante aquí es que, mediante etiquetas en los comentarios, hemos definido la relación entre la entidad User y la entidad Address, y también hemos definido cada una de sus columnas (¡hasta podemos indicar que una columna sea autoincremental!).

Llegados a este punto, tenemos 3 ficheros ya creados: cli-config.php, Entity/User.php y Entity/Address.php. Desde el raíz de nuestro proyecto vamos a ejecutar lo siguiente:

$ doctrine orm:schema-tool:create

Si todo ha ido bien, nos saldrá un mensaje indicándonos que el esquema de base de datos se ha creado correctamente. Y si comprobamos el directorio, veremos que se ha creado un nuevo fichero, database.sqlite, que contiene la definición de nuestras dos tablas.

Usándolo en una aplicación web

Bien, ya hemos definido las entidades, hemos creado la base de datos, y sabemos cómo funciona el código de inicialización de Doctrine 2. Ahora vamos a ver el fichero index.php:

<?php

// (1) Autocargamos clases
require_once 'Doctrine/Common/ClassLoader.php';
$classLoader = new \Doctrine\Common\ClassLoader('Doctrine');
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Entities', __DIR__);
$classLoader->register();
$classLoader = new \Doctrine\Common\ClassLoader('Proxies', __DIR__);
$classLoader->register();

// (2) Configuración
$config = new \Doctrine\ORM\Configuration();

// (3) Caché
$cache = new \Doctrine\Common\Cache\ArrayCache();
$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);

// (4) Driver
$driverImpl = $config->newDefaultAnnotationDriver(array(__DIR__."/Entities"));
$config->setMetadataDriverImpl($driverImpl);

// (5) Proxies
$config->setProxyDir(__DIR__ . '/Proxies');
$config->setProxyNamespace('Proxies');

// (6) Conexión
$connectionOptions = array(
    'driver' => 'pdo_sqlite',
    'path' => 'database.sqlite'
);

// (7) EntityManager
$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);

// (8) Código de prueba
$user = new \Entities\User();
$address = new \Entities\Address();

echo 'Hola mundo!' . PHP_EOL;

// Introduce aquí el código que maneje $user y $address

Si nos fijamos, los 7 primeros puntos son exactamente iguales que en cli-config.php. En el punto 8 creamos dos objetos de nuestro modelo, ya listos para usar. ¡Pero cuidado! Antes de poder hacer cambios en la base de datos SQLite, debes asegúrate de que el usuario de tu servidor web tiene permisos de escritura en el fichero database.sqlite. Ahora podríamos añadir el siguiente código de ejemplo:

$address->setStreet("Calle Río tinto, 12");
$em->persist($address);
$em->flush();

echo "Insertamos dirección<br />" . PHP_EOL;

$user->setName("Pedro");
$user->setAddress($address);
$em->persist($user);
$em->flush();

echo "Insertamos usuario<br />" . PHP_EOL;

Simplemente tenemos que acceder desde nuestro navegador a ese fichero (o también mediante “php index.php”) para que PHP ejecute el código. Una vez hecho, podemos consultar la base de datos mediante sqlite3:

$ sqlite3 database.sqlite
SQLite version 3.6.22
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> select * from addresses;
1|Calle Río tinto, 12
sqlite> select * from users;
1|1|Pedro

¡Lo ha hecho todo él sólo por nosotros! Así de sencillo resulta trabajar con bases de datos con un ORM A partir de aquí empieza lo bueno: ya puedes guardar tus objetos de forma persistente en base de datos, sin tener preocuparte ni por crear las tablas, ni por SQL, ni nada. Céntrate en PHP

¡Gracias por leer!

Descargar el código fuente

Pero si ése no es tu caso, el cliente de escritorio remoto de Microsoft no te servirá; no hace una conversión previa de un teclado a otro, sino que envía a Windows tal cual las teclas que has pulsado.

Todo esto intenté antes de dar con la solución:

• Utilizar otro software, como VNC.
• Hacer uso de la combinación Alt+Ctrl, que en Windows emula la tecla AltGr. Además de ser incómodo, no muestra algunos caracteres como ‘{‘ o ‘\’.
• Hacer un mapeo de teclado personalizado modificando el registro.

Cuando ya creía haberlo probado todo, vi un foro en el que hablaban de CoRD, un cliente de escritorio remoto para Windows. Lo probé, y a la primera

Además de contar con las mismas funcionalidades que el de Microsoft, tiene unas cuantas cosas que lo convierten en un mejor cliente RDP:

• Se comporta mejor en el modo pantalla completa, ajustándolo a la resolución de tu monitor. Con el de Microsoft esto no ocurría, dejando una banda negra a cada lado.
• Interpreta y convierte de tu teclado al equivalente en Windows. Puedes escribir la arroba, llaves, almohadillas, o corchetes.
• Convierte la tecla cmd de Mac en la tecla Win.
• Puedes tener varias sesiones abiertas a la vez, pudiendo navegar entre ellas desde un cómodo panel.

Y además, es open source!

www.beautyoftheweb.com

En 33 lenguajes. Una gran noticia tanto para usuarios como para desarrolladores. Aunque todos esperamos que finalmente Microsoft recule y también permita instalarlo en Windows XP -hoy por hoy sigue siendo el sistema operativo más utilizado.

La instalación ha sido sencillísima; Desde la web BeautyOfTheWeb descargas el instalador, y éste se encarga de todo. Tras un reinicio, nuestro Windows ya está actualizado con IE9.

Nada más arrancarlo, detecta que hay numerosos addons que ralentizan el inicio del programa, de modo que nos muestra una ventana desde la que desactivar aquéllos que queramos, indicándonos también el tiempo que le toma a cada addon arrancar. Un detalle que se agradece mucho, y con el que estoy seguro que usuarios no avanzados sabrán maximizar el rendimiento de su navegador.

Una vez arrancado y listo para funcionar, nos encontramos con un navegador limpio, muy limpio. En mi opinión, más incluso que Google Chrome, puesto que en una sola fila localizamos:

1. botones de avanzar y retroceder
2. barra de navegación, con búsquedas, recargas, y detención.
3. pestañas
4. botones de inicio, favoritos y herramientas

Esto es todo

Compatibilidad con estándares

Pero lo primero es lo primero. Al comprobar el rendimiento de esta nueva versión con el conocido test Acid 3, esperaríamos conseguir un buen resultado cercano al 100. Pero eso no es así, obteniendo un 70:

Enorme FAIL, pero hay que entender que aun está en fase Beta y esto puede cambiar mucho en las próximas semanas.

Barra de navegación

Por lo demás, podemos comprobar cómo la barra de navegación es enormemente similar a la omnibar de Google Chrome, aunando buscador y barra de direcciones en uno, si bien se echa de menos prefijos de búsqueda como los que tenemos en Konqueror o en Chrome.

Gestor de descargas

Otras de las novedades que han sido desveladas ha sido el esperado gestor de descargas. Sencillo pero completo. Incluye una lista de los ficheros descargados, la localización, y las acciones posibles.

Developer Tools

De agradecer son estas herramientas, muy similares de nuevo a las de Google Chrome. Tenemos las siguientes secciones:

• HTML
• CSS
• Consola
• Script
• Profiler (¡viva!)
• Network

Otras consideraciones

Seguimos teniendo el botón de vista de compatibilidad. Personalmente lo veo innecesario, ya que al ser esta versión compatible con las anteriores, las páginas web específicas para una edición anterior podría hacer uso de las etiquetas meta destinadas al efecto.

Respecto a su limpieza, echo de más dos cosas: El botón “detener”, que bien podría ir junto al de refrescar, y el botón “página de inicio”.

Y en el menú de opciones podemos comprobar cómo no han innovado mucho, dando la sensación de volver al pasado al ser tan parecida a la de IE6

En resumen: Si bien se percibe en el rendimiento claramente que estamos ante una Beta, queda claro que Microsoft ha decidido no quedarse atrás. Una interfaz muy cuidada, un engine que promete, muy usable, y esperemos que ágil.

Estos días ha habido dos importantes novedades que seguro ayudarán a impulsar esta tecnología.

Google ahora indexa SVG

Por una parte, desde hoy Google indexa los ficheros SVG, tanto si está empotrado dentro de un documento HTML como si está en su propio fichero. Podemos ver ejemplos de cómo funcionan estas búsquedas: Ejemplo 1 y Ejemplo 2. De modo que ya cuentan con un tipo de fichero más a sumar a su extensa lista.

Una de las ventajas más evidentes es que esto impulsará el uso de SVG respecto a Flash. Recordemos que una de las principales funcionalidades de Flash es poder emplear gráficos vectoriales y animaciones en la web, cosa que también se puede realizar con SVG y JavaScript. Salvo que en el caso de Flash, la indexación de contenidos siempre ha sido bastante pobre. Esto con SVG parece que no pasará

IE9 se hace amigo de SVG

Y la segunda noticia viene de mano de Microsoft. Precisamente ayer publicaban en el IEBlog un artículo animándonos a que nos preparemos para SVG. A la vista de los resultados, han hecho una estupenda implementación de este estándar en su próximo navegador. Muestran además cómo se comporta, además de algunas pruebas en distintos navegadores.

Es de agradecer también que publiquen ejemplos de uso. No puedo evitar recordar mis inicios con la informática, cuando dibujaba polígonos en Basic o indagaba con la aplicación de renderizado 3d POV-Ray. Afortundamente, contamos con fantásticas aplicaciones para dibujar nuestros gráficos en SVG.

Recordemos que IE9 no saldrá hasta finales de 2010, a pesar de que este mes veremos la primera beta.

Y es que ya es la Fourth Platform Preview, la versión que precede a la Beta de IE9, donde ya podremos probar de verdad cómo funciona el nuevo navegador.

Una de las principales novedades que trae es la aceleración hardware HTML5, esto es, aceleración completa tanto en texto, gráficos, audio y vídeo. Presentan una completa lista de ejemplos demostrando el rendimiento del navegador, comparándolo además con otros.

SVG, ya plenamente funciona dentro de IE9. Lo venden, no sólo como una herramienta para realizar diagramas estáticos, sino como un una excelente elección que permite crear un nuevo escenario de animaciones.

La integración nativa de JavaScript, hasta ahora una pieza fuera del navegador. En IE9, su nuevo motor de JavaScript (Chakra), mejora muy notablemente el rendimiento si lo comparamos con sus antecesores. Como nota curiosa, parece que ya oficialmente han abandonado la terminología JScript para referirse a JavaScript. Además, han mejorado el árbol DOM.

Vemos también como siguen mejorando posiciones en la batalla por el mejor motor de JavaScript, superando ya las últimas versiones de Safari y de Firefox.

Todo parece indicar que para finales de este año, cuando salga IE9, realmente va a suponer el principio de una revolución en la web, ya que podremos por fin empezar a usar HTML5. Sólo veo una pega: No estará disponible para Windows XP, que a día de hoy, mantiene todavía una cuota de mercado de casi el 60%.

Más información, en IEBlog.

• Arquitectura basada en Modelo-Vista-Controlador.
• Seguridad, con un completo sistema de perfiles de acceso.
• Acceso a base de datos.
• Sistema de cachés.
• Gestión de errores.
• Administración de formularios.
• Sesiones.
• Plantillas.
• Utilidades para fechas, criptografía, XML, ficheros…

Con todo esto, podemos crear diferentes extensiones de Joomla!:

• Component. Son las extensiones más complejas. Se trata de aplicaciones completas que se ejecutan dentro del espacio de Joomla!. Tenemos muchas de serie, como por ejemplo el componente Content (/components/com_content/), que es el encargado de manejar los artículos, categorías y secciones.
• Module. Se trata de pequeñas piezas de contenido que se muestran en la página. A menudo, dependen de un componente, como es el caso del módulo “latest news” (/modules/mod_latestnews/). Otro ejemplo de módulos, son los menús. En los módulos, además, se debe especificar su posición dentro de la página.
• Plugins. Son bloques de código que se disparan ante determinados eventos. Antes de Joomla! 1.5 se los llamaba Mambots.
• Templates. Plantillas que modifican el aspecto visual de la aplicación web.
• Languages. Las extensiones de este tipo contienen ficheros que definen cadenas de texto traducidas para distintas partes de Joomla!.

A partir de Joomla 1.6, además, tendremos dos nuevos tipos de extensiones. Library, que se tratará de un bloque de código que contenta un conjunto de funciones relacionadas entre sí. Por ejemplo, para acceder a la API de Twitter. Y también se incluirá la extensión Packages.

Como vemos, la extensión más compleja y flexible son los components. Con ellos podremos crear, por ejemplo, una completa agenda de eventos o un sistema de ecommerce. Veamos cómo podemos crear un componente básico “Hola Mundo”. Vamos a utilizar la primera parte del ejemplo que viene en la documentación de Joomla!.

Modelo Vista Controlador

Lo primero es conocer el patrón Modelo-Vista-Controlador. Queda fuera del alcance de este artículo explicar en qué consiste, de modo que en resumen diremos que se trata de una arquitectura que permite dividir una aplicaciones en tres apartados:

1. Controlador, que es el que gobierna el comportamiento principal, y el que responde las peticiones del usuario. En Joomla: JController.
2. Vista. Se trata del código que se encarga de generar el contenido que se le devolverá al usuario. Generalmente en HTML. En Joomla: JView.
3. Modelo. Es una abstracción de los datos que usa la aplicación. Si bien normalmente encapsulan bases de datos, también pueden utilizar otros origines de datos como un feed RSS. En Joomla: JModel.

Crear árbol de directorios

El primer paso consiste en crear el siguiente árbol de directorio y ficheros:

Además de los ficheros en blanco index.html (Para prevenir accesos a los directorios), vemos que tenemos 5 ficheros:

1. /site/hello.php – Punto de entrara a nuestro componente
2. /site/controller.php – Fichero que contiene nuestro controlador.
3. /site/views/hello/view.html.php – Clase que extiende JView que se encarga de construir la vista
4. /site/views/hello/tmpl/default.php – Plantilla
5. /hello.xml – Fichero XML que indica a Joomla! cómo instalar el componente.

Crear el punto de entrada

Vamos a editar el fichero /site/hello.php y vamos a guardar en el lo siguiente:

/**
 * @package    Joomla.Tutorials
 * @subpackage Components
 * components/com_hello/hello.php
 * @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_2
 * @license    GNU/GPL
 */

// No direct access
defined( '_JEXEC' ) or die( 'Restricted access' );

// Require the base controller

require_once( JPATH_COMPONENT.DS.'controller.php' );

// Require specific controller if requested
if ($controller = JRequest::getWord('controller')) {
	$path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';
	if (file_exists($path)) {
		require_once $path;
	} else {
		$controller = '';
	}
}

// Create the controller
$classname	= 'HelloController'.$controller;
$controller	= new $classname();

// Perform the Request task
$controller->execute( JRequest::getVar( 'task' ) );

// Redirect if set by the controller
$controller->redirect();

¿Qué es lo que hemos hecho? Veámoslo paso a paso:

1. En primer lugar comprobamos que estamos ejecutando éste código dentro de Joomla mirando si está definido _JEXEC. En caso contrario, finalizamos la aplicación.
2. Cargamos con require_once nuestro controlador.
3. El siguiente bloque de código comprueba si se necesitan más controladores. Por ahora no es necesario, pero lo mantenemos ahí para un futuro.
4. Después, creamos el controlador. En este caso, siempre se creará un controlador de la clase HelloController(), dado que en este ejemplo, como vimos en el paso anterior, no hay más.
5. Posteriormente indicamos al controlador que lleve a cabo la tarea solicitada. Por defecto, si no hay ninguna, la tarea es ‘display’.
6. Finalmente, pasamos el control al controlador, para que, si fuera necesario, lleve a cabo una redirección.

Creamos el controlador

Nuestro controlador sólo hace una cosa: Mostrar el mensaje Hello World, de modo que no se hace necesaria ninguna manipulación de datos. Guardamos el siguiente código en /site/controller.php

 /**
 * @package    Joomla.Tutorials
 * @subpackage Components
 * @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
 * @license    GNU/GPL
 */

// No direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

jimport('joomla.application.component.controller');

/**
 * Hello World Component Controller
 *
 * @package    Joomla.Tutorials
 * @subpackage Components
 */
class HelloController extends JController
{
    /**
     * Method to display the view
     *
     * @access    public
     */
    function display()
    {
        parent::display();
    }

}

Como vemos, creamos una clase llamada HelloController que hereda a JController. Tan sólo define el método display(), pues es la tarea por defecto (Salvo que no se especifique otra). Este método tan sólo invoca al método JController::display(), que determina y carga la vista y plantilla a utilizar. En nuestro ejemplo, sólo tenemos una vista y una plantilla.

Crear la vista

La vista tan sólo carga datos y los guarda para usar en la plantilla. Para ello se usa el método assignRef(), donde el primer parámetro es el nombre de la variable en la plantilla, y el segundo la variable que se comparte.

Código de /site/views/hello/view.html.php:

/**
 * @package    Joomla.Tutorials
 * @subpackage Components
 * @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
 * @license    GNU/GPL
*/

// no direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

jimport( 'joomla.application.component.view');

/**
 * HTML View class for the HelloWorld Component
 *
 * @package    HelloWorld
 */

class HelloViewHello extends JView
{
    function display($tpl = null)
    {
        $greeting = "Hello World!";
        $this->assignRef( 'greeting', $greeting );

        parent::display($tpl);
    }
}

Y ahora definimos el código de la plantilla en /site/views/hello/tmpl/default.php:

<?php

// No direct access

defined('_JEXEC') or die('Restricted access'); ?>
<?php echo $this->greeting; ?>

Se trata de un fichero PHP convencional en el que tenemos accesibles todas las variables que hemos compartido desde la vista.

Juntándolo todo

Nos queda definir el fichero Manifiest que define el componente para poder instalarlo fácilmente (Sin tener que copiar los ficheros a mano y actualizar la base de datos nosotros). Contiene distinta información, como por ejemplo:

• Descripción del componente.
• Lista de ficheros que incluye.
• Un fichero opcional PHP que realizar tareas de instalación.
• Un fichero opcional SQL que se ejecuta al instalar o desinstalar

 Hello
 
 2007-02-22
 John Doe
 john.doe@example.org
 http://www.example.org
 Copyright Info
License Info
 
 1.01
 
 Description of the component ...

 
 
 
  controller.php
  hello.php
  index.html
  views/index.html
  views/hello/index.html
  views/hello/view.html.php
  views/hello/tmpl/default.php
  views/hello/tmpl/index.html
 

 
  
Hello World!

  
  
   hello.php
   index.html
  

 

Finalmente, guardamos en los ficheros index.html un contenido trivial, como por ejemplo:

<html><body bgcolor="#FFFFFF"></body></html>

Por último, comprimimos en un fichero ZIP el contenido de la carpeta com_hello, y ya podemos instalar nuestro componente desde el instalador de extensiones de Joomla.

Mostrando el componente

Ahora, para poder ver el resultado, debemos consultar el componente. Para ello, debemos acceder a la siguiente URL:

/index.php?option=com_hello&view=hello

Vemos que no se define ninguna tarea (Recordemos que por defecto se usa Display). En caso de querer ejecutar otra tarea, tendríamos que definir el parámetro GET task, por ejemplo para la tarea ‘save’:

/index.php?option=com_hello&view=hello&task=save

En este caso en concreto, se trata de establecer las configuraciones por defecto de los artículos en Joomla!, esto es, los parámetros avanzados que se pueden configurar para cada artículo en el menú de la derecha. El método de fuerza bruta es ir artículo por artículo quitándolo. Pero esto no escala

Pues bien, si queremos desactivar de una vez por todas los iconos de exportar a PDF, enviar por email e imprimir, simplemente debemos ir al menú Contenidos, apartado Gestor de artículos. Una vez ahí, pulsamos el botón Preferencias, y ya podremos activar los valores por defecto.

Simplemente marcamos la opción “ocultar” de los campos:

• Iconos
• Icono PDF
• Icono Imprimir
• Icono e-mail

Y de paso, para quitar más basura, oculto también:

• Nombre del autor
• Creado en fecha y hora
• Modificado en fecha y hora
• Muestra navegación
• Enlace leer más…
• Valoración/Votación de artículos
• Impresiones
• Nombre de la sección
• Título de la categoría

De esta forma, Joomla! parecerá un poquito menos Joomla!, algo que siempre procuro hacer con todo CMS: Que no se aprecie el software que hay por debajo.

Si consultamos la Wikipedia en castellano veremos que:

• Google Chrome es un navegador web desarrollado por Google y compilado con base en componentes de código abierto [...]
• Chromium es el proyecto de software libre detrás de Google Chrome[...]

O dicho de otra forma, Google Chrome es la compilación y el paquete que Google hace del software Chromium. Algo así como los distints paquetes que las distribuciones de GNU/Linux hacen del kernel.

Si eso es todo… ¿Qué más me da usar uno u otro? ¿No son lo mismo pero empaquetado por entidades diferentes? Bien, Google tiene una página explicativa al respecto que con vuestro permiso voy a traducir:

Bien, ahora queda un poco más claro. La principal diferencia que veo yo es el soporte para los codecs de compresión de audio y vídeo. Google, como compañía, está dispuesta a pagar royalties por la licencia de la patente de dichos codecs, no así las ediciones libres.

Por otra parte, mientras nada me haga pensar lo contrario, creo que el nivel de calidad que ofrecen las distribuciones Linux en general es bastante elevado, por lo que no considero que ese hecho otorgue ventaja a Google Chrome.

¿Cuál elegir? Yo personalmente seguiré usando Chromium como navegador secundario y Firefox como primario. Principalmente para promover el uso de tecnologías libres y estándar, como son Vorbis para el audio y Theora para el vídeo.