"Tutoriales" entries

Un formatter permite seleccionar como se mostrará un campo CCK en diferentes lugares. Muchas veces los formatters que vienen configurados por defecto no nos sirven. Para desarrollar un formatter personalizado se deben implementar tres hooks:

• [module]_field_formatter_info: registra el nuevo formatter en el sistema, devuelve un array con nombres, descripciones, tipos a los que se aplica el formatter, etc.
• [module]_theme: registra las funciones theme encargadas de renderizar el campo. Debe registrar la función siguiente.
• theme_[module]_formatter_[formatter]: una función para cada formatter, renderizan el campo y son las funciones theme registradas en la función anterior.

Por ejemplo, en un módulo de nombre "foo" un formatter sencillo de nombre "bar" que renderizará una cadena de texto en vez del valor de un campo (sencillo a la par que absurdo):

 t('Bar'),
        'field types' => array('text'),
        'multiple values' => CONTENT_HANDLE_CORE,
  );
  return $formatters;
}

function theme_foo_formatter_bar($element) {
  return "Hello, Bar!";
}

function foo_theme($existing, $type, $theme, $path) {
  return array(
    'foo_formatter_bar' => array(
      'arguments' => array('element' => NULL),
    ),
  );
}

Et voilà!

Repasando el último podcast de JavaHispano me viene a la mente el concepto de la excelencia técnica en nuestra profesión.

En dicho podcast se habla de metodologías ágiles de desarrollo que, en contraposición con las tradicionales o predictivas, profesan la cercana relación con el cliente y el constante cambio. Este último requiere sin duda, además de la eliminación de la burocracia de los funcionales y el papeleo innecesario, de la excelencia en nuestro trabajo.

Una de las características que más me llaman la atención en muchos de los proyectos en los que he participado es la ausencia de la responsabilidad consciente sobre el código. Característica que a mi parecer es básica para garantizar la excelencia técnica.

Normalmente el código lo escribe una persona y lo modifica otra y otra y otra sin que ninguna de ellas se responsabilice del resultado final. Esto lleva a tener sistemas ilegibles, con diferentes metodologías para nombrar variables, diferentes metodologías para tabular el código y diferentes patrones y estructuras aplicadas mezcladas en el mismo módulo, archivo o función. Existen muchas formas de garantizar que esto no pase, pero todas ellas pasan por introducir el concepto de responsabilidad.

Tras publicar dos artículos sobre el tema y dado el interés que despierta esta tecnología en la comunidad, hemos decidido realizar un tutorial exhaustivo que examine las posibilidades de JSON-RPC-Java con las explicaciones, snippets y ejemplos para que podáis incorporarla a vuestros proyectos.

JSON-RPC-Java es una tecnología que permite realizar comunicaciones Ajax entre el cliente y el servidor J2EE, hacer llamadas a funciones de clases Java desde JavaScript, con capacidad para serializar objetos Java y convertirlos en objetos JavaScript y todo ello, de forma transparente al programador.

Funcionamiento básico

Para comprender el funcionamiento de JSON-RPC-Java se debe comprender tanto el funcionamiento de la parte de servidor como del cliente JavaScript.

Desde el punto de vista del servidor Java lo primero es desarrollar las clases que serán accesibles desde el cliente. Para hacer públicos sus métodos y funciones debemos registrar una instancia de nuestra clase en un objeto JSONRPCBridge que previamente habremos creado y guardado en la sesión HTTP. Este objeto es el encargado, junto a un Servlet que más adelante aprenderemos a instalar, de comunicar a JavaScript la estructura de nuestras clases y de gestionar la comunicación entre ambas partes.

La ley de Demeter es un principio básico de la programación orientada a objetos. Sorprende al conocerlo su gran utilidad, sus resultados en proyectos de todos los tamaños y el poco conocimiento que la comunidad de desarrolladores tiene de su existencia.

Su enunciado básico es:

A method of an object should invoke only the methods of the following kinds of objects:

1. itself
2. its parameters
3. any objects it creates/instantiates
4. its direct component objects

Mejora de forma considerable la encapsulación y la cambiabilidad de nuestro código. Explicaremos en este artículo cual es su significado y como detectar los lugares en nuestro código donde no se cumple.

Una forma de comprender mejor esta ley podemos dar la vuelta al enunciado y enumerar los casos prohibidos: no se debe llamar a métodos de los objetos devueltos por otros métodos.

El caso más común que debemos evitar son las cadenas de métodos, de la forma:

a.getX().getY().getValue();

y sustituirlas por funciones que realicen dicha acción:

a.getXYValue();