• Separación del formulario de las vistas. Ahora los formularios serán un objeto sobre el que puedes realizar numerosas operaciones. La clase encargada es Zend_Form.
• Cada elemento del formulario es también un objeto, que hereda de Zend_Form_Element. Es decir, si añades un campo de texto, éste será también un objeto que, entre otras propiedades contiene su nombre, valor, etiqueta, descripción, errores, filtros, validadores, etc. Están todos los elementos de un formulario HTML disponibles en la biblioteca de Zend_Framework
• Filtros, gracias a Zend_Filter. Podemos hacer que un elemento filtre de forma limpia y elegante su valor, como por ejemplo conversión a mayúsculas. Zend Framework trae un gran número de filtros.
• Validaciones, gracias a Zend_Validate. Del mismo modo que podemos filtrar, también podemos añadir validaciones. Por ejemplo, que un valor numérico se encuentre en un determinado rango, que cumpla una determinada expresión regular, o que no exceda un determinado número de caracteres.
• Comprobar el formulario. ¿Queremos saber si el formulario que ha completado el usuario es correcto? Simplemente invocamos el método isValid() del formulario, y sabremos si ha sido correcto.
• Definir el formulario en un archivo .ini o .xml.

Pero volviendo al hilo, cada vez que tengo que retomar Zend_Form, hay un punto en el que me atasco: los decoradores. Su funcionamiento se basa en el patrón decorador.

¿Y en qué afecta esto a Zend_Form? Como hemos dicho, tanto el formulario como los campos de éste, son objetos. Al renderizarse en HTML, muy seguramente, queramos modificar el modo en que se muestran por defecto. Y ahí es donde entra en juego el patrón decorador: Añadimos nuevas funcionalidades dinámicamente, para que por ejemplo un campo de texto esté envuelto en un div, que a su vez pertenece a una celda td.

Nota: La mayoría de la información de este artículo, y ejemplos, los he sacado del artículo Decorators with Zend Forms de la Zend Developer Zone.

La mayoría de elementos de un formulario (por ejemplo un campo de texto, un textarea o un combo) tiene una serie de decoradores “de serie” (el orden importa):

1. ViewHelper – Es el encargado de renderizar el propio elemento
2. Errors – En caso de que haya errores (por ejemplo, el valor introducido supera el tamaño máximo), lo mostraría este decorador.
3. HtmlTag – Envoltura, por defecto con la etiqueta <dd> para el ViewHelper y Errors.
4. Label – Etiqueta, envuelta en la etiqueta <dt> por defecto.

Se invocan (y anidan de dentro a fuera) en orden, de modo que la anterior pila generaría algo similar a lo siguiente:

$label->render($htmlTag->render($errors->render($viewHelper->render(''))));

Visto paso a paso, esto es lo que ocurriría:

''

<input name="foo" id="foo" type="text" value="" />

<input name="foo" id="foo" type="text" value="" />
<div><ul>
    <li>...</li>
</ul></div>

<dd>
    <input name="foo" id="foo" type="text" value="" />
    <div><ul>
        <li>...</li>
    </ul></div>
</dd>

<dt><label for="foo">Foo</label><dt>
<dd>
    <input name="foo" id="foo" type="text" value="" />
    <div><ul>
        <li>...</li>
    </ul></div>
</dd>

¿Cómo modificamos la forma en que se genera el código por defecto? Hay dos vías.

La primera nos permite añadir nuevos decoradores al comienzo de la pila, eliminar alguno de ellos, y/o modificar la ubicación en que se muestra alguno de los que ya hay. Por ejemplo, esto extraería el decorador ‘label’ de la pila de decoradores del elemento, y modificaría su ubicación (valores posibles appendo o prepend):

$label = $element->getDecorator('label');
$label->setOption('placement', 'append');

Del mismo modo, podríamos eliminar de la pila de decoradores el decorador ‘label’ así:

$element->removeDecorator(‘label’);

La segunda es más potente, y nos permite redefinir toda la pila

$element->setDecorators(array(
    'ViewHelper',
    'Description',
    'Errors',
    array(array('elementDiv' => 'HtmlTag'), array('tag' => 'div')),
    array(array('td' => 'HtmlTag'), array('tag' => 'td')),
    array('Label', array('tag' => 'td')),
));

Cada elemento dentro del array es un decorador, de modo que en este caso tenemos 6: ‘ViewHelper’, ‘Description’, ‘Errors’, ‘HtmlTag’, ‘HtmlTag’, ‘Label’.

A cada elemento le podemos añadir opciones, como por ejemplo el tag a utilizar. En ese caso, en lugar de utilizar sólo su nombre, lo haríamos así:

array('decorador', array('opción' => 'valor'))

Además, si usamos dos veces un mismo decorador, debemos necesariamente etiquetarle con un nombre que lo identifique de manera unívoca, ya que sino, el último decorador de ese tipo que se añada, sustituirá al anterior. Para poner una etiqueta, lo haríamos así:

array( array('etiqueta' => 'decorador'), array('opción' => 'valor'))

Explicación:

Ahora ya conocemos la dinámica de cómo decorar un elemento de un formulario. Hemos visto sólo unos pocos (ViewHelper, Description, Errors, HtmlTag y Label). Por cada tipo de campo (input text, button, file, etc.) hay un decorador, siendo ViewHelper sólo un atajo que deduce cuál de ellos usar. Estos algunos decoradores más (aquí la lista completa):

• Callback – Si no nos queremos complicar, podemos definir una función callback que reciba como parámetro el elemento, para con una sentencia similar a ésta, devolver el nuevo contenido:
  return ’<span>’ . $element->getLabel() . ”</span>”;
• Form – Es el decorador por defecto del propio formulario. No lo hemos dicho, pero no sólo los elementos del formulario tienen decoradores. También los tienen los formularios en sí.
• FormElements – Este es el encargado de renderizar cada uno de los elementos dentro de un formulario, es decir, es el que envuelve a nuestros elementos.
• Image – Para renderizar una etiqueta de tipo img en el formulario. Útil por ejemplo cuando queremos mostrar en un formulario de actualizar perfil de usuario su avatar activo.
• ViewScript – ¿Que todo lo anterior resulta demasiado farragoso para un simple formulario? No hay problemas. ViewScript permite diseñarlo a la antigua usanza, con una plantilla. Todo esto sin tener que dejar de lado toda la potencia y facilidades que nos ofrece utilizar Zend_Form como sustituto de los formularios no gestionados.

Hay mucho más que ver sobre los decoradores, como por ejemplo, aprender a definir nuestros propios decoradores, o saber cómo hacer uso de ViewScript. En cualquier caso, Matthew Weier O’Phinney lo tiene todo explicado de maravilla en el artículo del Zend Developer Zone que enlazaba al comienzo.

Gracias por leer este artículo

Lo primero que me llama la atención, es un párrafo que dice lo siguiente:

La herramienta de gestión de contenidos proporcionará a la Fundación Biodiversidad la capacidad de modificar en su totalidad el diseño, imagen del portal Web y todos sus contenidos. Todo ello de una manera sencilla sin requerir conocimientos de programación ni HTML.

Lamentablemente no existe tecnología que permita realizar esto. Existen multitud de editores WYSIWYG, aplicaciones que permiten editar textos de forma enriquecida sin necesidad de lidiar con CSS o HTML. Pero no existe nada que permita modificar el aspecto de toda una web sin necesidad de tener conocimientos de HTML y/o CSS. Ni siquiera aplicaciones como WordPress, Joomla o Blogger, todas ellas conocidas por lo sencillas de manejar que son, permiten nada remotamente parecido. Permiten instalar plantillas, eso sí, desarrolladas por gente que sí tiene conocimientos técnicos.

Pero sigamos. En otro párrafo nos indican esto:

La propiedad intelectual de los trabajos realizados por el adjudicatario pertenecerá a la Fundación Biodiversidad.

Todos desarrollamos código reutilizable. Por ejemplo, si un día diseño una página web en la que hay un sistema de gestión de usuarios, procuraré que este código se pueda reutilizar para otros proyectos. Es bastante frecuente contar con un buen número de “bloques” de código que reutilizas para ensamblar nuevos proyectos. Esto permite abaratar costes sin perder en calidad.

Pero volvamos con la cita anterior. Si toda la propiedad intelectual (esto incluye el software) pasa a pertenecer a la Fundación Biodiversidad, ¿qué ocurre con nuestros anteriores clientes? ¿Sus aplicaciones serán en parte propiedad de esta fundación? O una pregunta todavía más interesante, ¿y si el software utilizado, bien desarrollado por nosotros, bien por terceros, está licenciado como software libre? Por favor, si me equivoco agradecería alguna explicación, pero hasta donde yo sé, la única solución viable consiste en desarrollar un software desde cero para este proyecto.

Pero hay más puntos interesantes a analizar:

Además la Fundación Biodiversidad se reserva el derecho a ampliar los contenidos sin que el presupuesto varíe.

Al definir un proyecto siempre se olvida algún contenido o requisito. Esto es normal. Si presupuesto una web que inicialmente cuenta con 30 documentos, pero finalmente se realizan 33, muy posiblemente el precio no variará con respecto al presupuesto inicial (salvo que se trate de apartados especialmente costosos en tiempo, y siempre indicándoselo con antelación al cliente).

Pero que te obliguen a firmar unas condiciones en las que te comprometes a añadir todos los contenidos extra que te proporcionen, únicamente fiándote de su buena fe, lo veo abusivo. ¿Quién te garantiza que finalmente no será el doble de lo estimado? Personalmente considero una cláusula así como un claro indicativo de la seriedad del cliente con el que vas a trabajar. Por suerte no he tenido ningún cliente así; la gente entiende que si se salen de los requisitos iniciales, es normal pagar por ello.

Gracias a estas cositas, muchos diseñadores que hasta ahora se mostraban reticentes, se animarán a usar esta API para sus páginas.

Aquí tenemos un ejemplo de qué se puede hacer:

1. Canonizar la URL de inicio. ¿Con o sin www? ¿Con barra final o sin ella? Sólo puede quedar una
2. Escoger entre enlaces relativos y absolutos. Nos aconsejan usar siempre enlaces absolutos, sobre todo porque refuerzan nuestra URL.
3. Utiliza una buena sintaxis en las URLs de los enlaces. Por ejemplo, debemos omitir el fichero por defecto de una carpeta (Típicamente index).
4. Utiliza el atributo title en enlaces internos. En los enlaces que apuntan a tu propia página completa el atributo title con una descripción de la página de destino.
5. Identifica la URL canónica de cada página. Ya sabéis, como en el punto 1, pero para todas las páginas.
6. Minimiza el número de parámetros de URLs dinámicas. Suelen ser problemáticas para los bots que rastrean la página.
7. Evita usar IDs de sesiones o cookies. Dificultarás el rastreo a los bots.
8. Ten al menos un enlace interno a cada página. Lógico. Todos los documentos deben ser accesibles.
9. Limita el número de enlaces de una página. Nos aconsejan que un documento no contenga más de 100 (Salvo que sea necesario).
10. Evitar que el rastreador siga un enlace. Mediante rel=”nofollow”. Cuanto más tiempo dedique a las páginas no interesantes, menos dedicará a las que de verdad nos interesan.

Sobre los links, también hicieron unos artículos muy interesantes titulados “El bueno, el feo y el malo” (Parte 1 y Parte 2).

Actualmente están disponibles:

Estoy seguro que tanto mi hermana Olalla como mi cuñado Samer se alegrarán de tener esta herramienta, y seguro que la utilizarán

Aquí os dejo un ejemplo en funcionamiento en Árabe:

Y aviso otra vez: HAY SPOILERS, de modo que cuidadito.

Lo primero es lo primero; Este capítulo doble es impresionante. Ya desde el primer minuto nos inunda con respuestas, y cuanto más avanza, más emocionado estás ante la vorágine de aclaraciones que da.

Sin duda lo que más impactado me ha dejado ha sido el hecho de que John Locke esté muerto. ¿Quién ha estado entonces toda la temporada hablando y actuando en su nombre? Pues ni más ni menos que el némesis de Jacob, como ya le han apodado en lostpedia. Sensacional el momento en que te encajan las piezas y descubres quién es este Locke y cómo ha encontrado “el agujero” para matar a Jacob.

Uno de los personajes que más me han intrigado siempre ha sido Richard Alpert. En este capítulo nos revela que su nombre real es Ricardo. Y yo tengo una teoría… Al comienzo del episodio vemos un navío, que a mi parecer es de la época de los grandes descubrimientos geográficos, que Jacob ha “llevado” a la isla. ¿Quién iba a bordo de dicho navío? Pues yo lo veo claro: Richard. Lo cual despierta en mi cierta esperanza patria; Ricardo es un español a bordo de un navío conquistador de finales del siglo XV.

Por otra parte hemos conocido finalmente la respuesta a “What lies in the shadow of the statue?“, cuya respuesta es en latín, el idioma de “los otros”. Luego entonces, ¿quiénes son Ilana y Bram? ¿A que grupo pertenecen? ¿Cuáles son sus intereses? ¿Y porqué Jacob dice “ya vienen” en su lecho de muerte?

Otro de los momentos estelares es el final, cuando vemos cómo Juliet logra detonar la bomba, aunque tampoco me resulta tan enigmático el momento: Queda una temporada y todos esos personajes (Jack, Kate, Sawyer, Hurley, Jin, Milles, etc) no pueden morir.

Otra de mis teorías es que “whatever happened, happened”, de modo que “el incidente” es el mismo que ocurrió en la iteración anterior (Porque esto es un bucle, ¿no? ). No se puede cambiar el pasado, y la detonación de la bomba siempre ha formado parte de la historia de la estación del Cisne.

¿Qué os ha parecido a vosotros? ¿Qué teorías tenéis? No sé si aguantaré 8 meses de espera hasta que llegue la sexta temporada antes de que me haga el hara-kiri.

Echemos un primer vistazo a un singleton en PHP:

class Example
{
    // Hold an instance of the class
    private static $instance;

    // A private constructor; prevents direct creation of object
    private function __construct()
    {
        echo 'I am constructed';
    }

    // The singleton method
    public static function singleton()
    {
        if (!isset(self::$instance)) {
            $c = __CLASS__;
            self::$instance = new $c;
        }

        return self::$instance;
    }

    // Example method
    public function bark()
    {
        echo 'Woof!';
    }

    // Prevent users to clone the instance
    public function __clone()
    {
        trigger_error('Clone is not allowed.', E_USER_ERROR);
    }

}

Sencillo, verdad? Pero este es el esqueleto de un singleton básico. Se declara como privado el constructor, de forma que si necesitas una instancia del objeto debas hacerlo necesariamente por el método estático Example::singleton(). Este método construye una nueva instancia, o bien devuelve la que ya había (Almacenada en el atributo estático $instance). Sin embargo la clase que yo necesito debe cargarse por defecto de memoria, y almacenar el objeto de nuevo cuando éste se destruya. La solución aquí:

class ShoppingCart
{

    private $_items;
    private static $_instance;
    private static $_namespace = "spp";

    private function __construct()
    {
        $this->_items = Array();
    }

    public function __destruct()
    {
        $shopping = new Zend_Session_Namespace(self::$_namespace);
        $shopping->object = serialize(self::$_instance);
    }

    public function __clone() {
        throw new Exception("Cannot clone singleton!");
    }

    public static function singleton()
    {
        $shopping = new Zend_Session_Namespace(self::$_namespace);

        if (!isset(self::$_instance)) {
            if(isset($shopping->object)) {
                self::$_instance = unserialize($shopping->object);
            } else {
                $c = __CLASS__;
                self::$_instance = new $c;
            }
        }

        return self::$_instance;
    }

    public function addItem($id, $quantity)
    {
        // Código que añade un nuevo item
    }

    public function removeItem($id)
    {
        // Código que elimina un item
    }

    // Resto de funciones del carrito de la compra
}

Básicamente funciona igual, excepto que antes de crear un nuevo objeto, comprueba si hay alguno en el espacio de nombres de memoria asignado en el atributo estático $_namespace. Igualmente, cuando el objeto se destruye automáticamente por el recolector de basura, se serializa para guardarse la nueva versión en memoria.

Es importante darse cuenta de esto último: El método __destruct() no funcionará si ya hemos finalizado la sesión del usuario mediante session_write_close(). Por esa razón, en algunos casos tendremos que llamar explícitamente al destructor antes de que se cierre la sesión. Resulta que el método para redirigir a otra página Zend_Controller_Action::_redirect($url) cierra la sesión. Me he vuelto loco hasta que he averiguado la razón. Se corrige simplemente llamando a ShoppingCart::__destructor() antes de hacer la redirección.

1. El individuo ‘A’ dice: Lo que yo hago aparentemente es correcto. En cambio tu postura es perjudicial.
2. El individuo ‘B’ argumenta: Tú haz lo que te parezca bien a ti y yo lo que me parezca bien a mi.

Veamos algunos ejemplos…

Analizando el problema, vemos que en todos estos casos hay un individuo que se siente atacado e intenta justificar sus actos alegando libertad de elección. Pero es que, si tu libertad de decisión perjudica a la sociedad en conjunto, o va en favor de los gustos/ideas/intereses de sólo unos pocos, entonces muy posiblemente no sean aceptables (Aunque sean legales).

Por ejemplo, los defensores del creacionismo dicen que no se puede demostrar que su teoría es falsa. Nos ha jodido, tampoco se puede demostrar que Terelu exista (Quizá es un implante en nuestra psique), ni que sólo somos personajes de un enorme juego de rol. La demostración corre a cargo del que defiende la teoría, del mismo modo que los defensores de la evolución lo justificamos con el método científico. Llegados a este punto en el que queda claro quién actúa en favor de la sociedad, comienza el lamento y lloriqueo de los defensores de lo indefendible.

Ellos lo saben. Los argumentos que van contra sus ideas les dejan desnudos, y en un último intento por defender lo indefendible argumentan ese triste “Pero es que yo a ti no te critico“. Pues claro que no me criticas, como que no puedes.

Y es que, aunque lo irracional forme parte del ser humano, no debe formar parte de la sociedad. Por eso no tenemos porqué aceptar vuestras ideas.

Disclaimer: Como dijo Álex hace poco, Esto ha sido un vómito de ideas sin masticar demasiado y probablemente alguien me rebata algo y piense “joder, pues tienes razón.