Hoy vamos con un truco para todas aquellas personas que utilizan el módulo de Panels en Drupal y quieren limitar la visualización de distintos widgets de contenidos en paneles de tipo nodo, dependiendo de la taxonomía a la que pertenezca el nodo visualizado.

Dentro del panel que estemos configurando (supongo que todos nuestros nodos tiran de un mismo panel), añadimos un contenido nuevo, pongamos un banner que solo queremos que salga en los nodos que pertenecen a la taxonomía/taxón “XYZ”. Para limitarlo, solo tenemos que añadir a dicho widget una nueva regla de visibilidad (Visibility rules), seleccionar que será de tipo “code PHP” e introducir el siguiente código:

$clave = 'XYZ';
$q = explode("/", $_GET['q']);if(count($q) > 1)
{$node = node_load($q[1]);
$terms = taxonomy_node_get_terms($node);
foreach($terms as $term) {if($term->name == $clave)
 {return TRUE;}}}return FALSE;

Por supuesto, no olvidéis indicar que el tipo de contenido introducido es PHP. Cambiamos “XYZ” por el nombre de la categoría en la cual queremos que salga y… listo!

Este es un claro ejemplo de Drupal llevado al extremo de la personalización y “toqueteo”, pero no ha hecho más que volver a demostrar el potencial que tiene este CMS para crear verdaderas aplicaciones que puedan ser utilizadas como base de negocio de una empresa.

Ya es la hora de que entren aquellas personas que van a dedicarse al mantenimiento evolutivo del proyecto, y sólo puedo esperar que lo traten con mucho mimo.

Cesar y Alex han tenido una gran parte de la “culpa” de que esta nueva versión viese la luz, al segundo de ellos, Alex, mucha suerte en Asturias, vas a vivir como un rey y a ser muy feliz.

Ahora, como corresponde a este negocio (al igual que muchos otros), tocará cerrar un libro y después de un par de días de vacaciones (que creo que me merezco ), empezaremos con un nuevo proyecto, todo nuevo, y a seguir aprendiendo.

Es una lástima, pero hay que admitir que actualmente bajo PHP no existe ninguna librería que esté minimamente a la altura, teniendo que recurrir a librerías del estilo FPDF para la exportación en PDF… y por supuesto diseñando los informes “a manini”.

Por lo tanto, pongámonos manos a la obra y busquemos una forma de unir PHP y Java, así podremos utilizar JasperReports desde una aplicación PHP. Usaremos una librería llamada php/Java Bridge, que nos permitirá realizar llamadas a métodos Java desde el código PHP de la aplicación. Aunque no es la única existente en el mercado y podamos encontrar otros bridges como Quercus, será la que utilice en este post por ser gratuita y cumplir la funcionalidad que necesitamos, utilizar JasperReports desde PHP.

No voy a reinventar la rueda, por lo que os invito a leer este tutorial de adictosaltrabajo.com sobre el cual realizaré algunas anotaciones.

Os recomiendo bajaros desde el website de JasperReports el paquete completo (son unos 70 y pico megas), dado que incluye todas las librerías de las que puede depender su funcionalidad. De esa forma evitamos tener que bajarlas a mano una por una.

Con respecto al bridge, no es necesario que para realizar algunas pruebas os descarguéis ningún contenedor de aplicaciones como tomcat o resin, el mismo paquete incluye un pequeño contenedor que podréis ejecutar con el siguiente comando:

Os pedirá que seleccionéis el socket y puerto y estará listo para funcionar.

En los próximos días haré algunas pruebas de rendimiento, cuando tenga algo de tiempo, a ver si realmente merece la pena y puede ser útil en un entorno de producción.

Como es habitual, basándonos en que los dos buscan resolver una funcionalidad definida, en este caso ser un CMS, podemos resumir sus diferencias de la siguiente forma: Joomla busca ser un gestor sencillo, intuitivo y fácil de implementar mientras que Drupal sacrifica sencillez a cambio de una flexibilidad y posibilidad de ampliación infititamente superior a la de su homólogo.

Y en este punto nos encontramos, a lo largo de los años me he encontrado ya con demasiados proyectos que han sufrido el mismo problema, lo que los anglosajones definen como “hit the wall” al utilizar Joomla: una mala planificación incita al uso de este gestor pensando en “lo bonito que es” y lo “fácil que resulta utilizarlo”. La pesadilla ocurre cuando se intenta ampliar la funcionalidad de la página y empiezan los dolores de cabeza: limitaciones en la lógica de tratamiento de los datos, limitaciones en las modificaciones visuales… resulta que lo que en un principio parecía sencillo se vuelve en contra del usuario.

Es fácil encontrar ejemplos, entre ellos los que tengo más cercanos ahora mismo: en Joomla entras en el administrador, creas tus secciones y categorías y publicas contenidos. A partir de ese momento ya tienes el portal. Por un momento pensemos que queremos definir taxonomías (por ejemplo varios árboles de categorización), distintos tipos de contenidos, vistas personalizadas… paremos de contar, con Joomla es “casi” imposible, y digo casi porque existir, existen módulos que intentan crear esa funcionalidad… aunque sin demasiado éxito por el momento.

Este resulta ser un grave problema que deja muy tocado al proyecto, y además es una “enfermedad” que se repite constantemente. Son proyectos que en un inicio buscan tener un coste menor y con un periodo de desarrollo más corto… pero que en algún momento de su vida por su crecimiento necesitan incorporar nuevas funcionalidades, y ahí se acabó lo bueno.

Sin embargo, no vayamos a pensar que Drupal es la panacea y que el uso de Joomla es un error en todos los casos. Drupal no es intuitivo, ni para el usuario ni para el desarrollador. Necesita mucho más trabajo que Joomla para crear un portal “comestible”, algo que los usuarios y editores puedan utilizar sin problemas… y eso por supuesto implica tiempo y dinero. Es bastante lógico que se dé esta situación si pensamos que Drupal intenta no poner limitaciones de ningún tipo al desarrollo de un proyecto con el fin de que pueda ser ampliado sin encontrarse con paredes que impidan la creación de funcionalidades.

¿Entonces qué hacemos? Respuesta rápida: pararse a pensar. Respuesta larga: analizar correctamente las necesidades actuales y la previsión de las necesidades en un futuro medio (1-2 años). Si tenemos claro que el portal no va a cambiar, que sólo mostraremos contenidos con una categorización simple, que no querremos incluir funcionalidades más allá de lo que los módulos pueden hacer y que no resultará un problema encontrarse con limitaciones, Joomla es la respuesta: saldrá más barato y se tendrá en menos tiempo.

Si no tenemos claro que lo anterior se vaya a cumplir, mi consejo será el de utilizar Drupal. Si, el desarrollo será sensiblemente más caro (aunque sólo sensiblemente), y a cambio de sacrificar un poco de usabilidad, en el futuro nos habrá salido más rentable. ¿Rentable? Si, ya son unos cuantos los proyectos que he visto en los que después de pocos meses hay que “tirar” la plataforma Joomla y volver a hacer el desarrollo en Drupal, incluyendo los costes de la migración de todos los contenidos.

Nos descargamos wsdl2php desde aqui. Esta pequeño script parseará el WSDL que le indiquemos y nos creará una fichero con la clase SoapClient de PHP5 lista para usar junto a todas las clases que ofrezca el servicio, es decir, nos quita todo el trabajo de encima.

Sólo nos faltará crear un script para lanzar la ejecución:

<?php
require_once 'ClasesCreadas.php';
$client = new ClasesCreadas();
print_r($client->LlamadaAEjecutar($parametros);
?>

A veces las cosas fáciles son las que mejor funcionan

Para ponernos en situación, tenemos una especie de modelo editorial donde se almacenan cantidades más ó menos importantes de datos, desarrollado en java con toda la pesca incluída: Spring, Hibernate y usando MySQL como BD. Meses atrás se hizo a toda prisa una aplicación web de consulta, en este caso en PHP. Si, se que alguno querrá arrancarse los ojos al leer esto pero: el código de PHP lanza querys directas contra la BD (es decir, se pasa el modelo de ORM de Hibernate por los santos)… que queréis, se hizo en día y medio, cosas de los plazos.

Por si alguno todavía no se ha dado cuenta, eso tiene un grave problema (dejando de lado que es una chapuza increíble) y es que requiere trasladar todos los cambios que se hagan en el modelo a nuestra aplicación PHP (y normalmente suele pasar que se olvida y falla en el peor momento). A la hora de cambiar esto, se podría optar por utilizar algún tipo de implementación PHP sobre JAVA tipo Quercus (que ya utilizamos en otra rama), pero viendo los dolores de cabeza que ha dado, prefería evitarlo…

¿Solución? Servicios Web. ¿SOAP? ¡Mucho lio! … Mejor solución: REST (Representational state transfer): una solución de arquitectura “parida” para las necesidades justas que tenemos, y en este caso, limitadas a peticiones GET y algún POST (quizás para las búsquedas…). Ya tenemos nuestra solución: servicios web REST que den una salida JSON. El motivo de dar una salida JSON es evidente: queremos que sea interpretado por PHP, el cual tiene las funciones específicas para ello, y de esa forma no nos limitamos a ninguna arquitectura (nunca se sabe…).

Ahora viene el lado servidor, tenemos que implementar los servicios web en JAVA y sobre todo, tenemos que mantener y aprovechar la arquitectura existente. Ah! Una última cosa… no podemos depender de un contenedor específico, por si acaso

De nuevo, solución: JAX-RS, la solución más sencilla que nos aporta JAVA para montar servicios REST. En este caso hemos utilizado una implementación que se llama Jersey (que queréis que haga si le ponen esos nombres…). Utilizando maven se ha vuelto muy sencillo, unas dependencias por aquí, otras por allá, y todo ready! Aqui os dejo el “getting started” de Jersey, si miráis el código os quedaréis muy sorprendidos, al fin y al cabo utiliza POJOs.

 1    // The Java class will be hosted at the URI path "/helloworld"
 2    @Path("/helloworld")
 3    public class HelloWorldResource {
 4
 5        // The Java method will process HTTP GET requests
 6        @GET
 7        // The Java method will produce content identified by the MIME
 8        // type "text/plain"
 9        @Produces("text/plain")
10        public String getClichedMessage() {
11            // Return some cliched textual content
12            return "Hello World";
13        }
14    }

Admito que he estado un par de horas pegándome con un conflicto de versiones de dependencias que tenían jersey e hibernate, causados por la librería asm, cosa de tener ya un sistema montado por detrás. Ahora mismo no lo recuerdo exáctamente, pero creo que hibernate utilizaba la rama 1.x de asm y jersey la 2.x, algunos métodos han cambiado y… POUM! Las últimas versiones de hibernate ya no tienen esa dependencia así que sólo había que incluirla en el ignore de maven para hibernate y todo solucionado. ¿Veis? Si hubiese mirado los foros de hibernate antes… me hubiese evitado ese tiempo de pelea con el tomcat (si, lo he montado sobre un tomcat, aunque supongo que termine en un resin).

Si alguno monta un servicio con esto, ya me enviará la URL para probarlo (si es público claro )

Hace tiempo trabajé con sus primeras versiones, cuando se hizo el fork desde Mambo, pero en estas últimas semanas por motivos profesionales he tenido que estudiar todo su código y estructura: ¡Que maravilla! Ya no sólo es que tenga una buena documentación, si no es que además su estructura modular es una maravilla. Una lectura más bien rápida de su API y ya estaba programando módulos y componentes. En el apartado de diseño y maquetado no son menos las ventajas del sistema, un simple fichero en el cual se incluyen a elección del diseñador los espacios organizados para módulos, y todo ello controlado por CSS (adaptable igualmente según módulos desde el administrador). Tengo cronometrado mi tiempo de instalación de Joomla en 4 minutos, aunque automatizando un script bash para la configuración de permisos, el tiempo todavía se podría reducir un par de minutos.

Aunque se supone que esto es compartido por cualquier CMS (y por desgracia no es siempre así), ahí va una lista de aquellos puntos que considero como verdaderos puntos fuertes de Joomla, y que lo hacen una solución que supera lo puramente amateur, pudiendo pasar a un entorno corporativo:

• Alta seguridad (nos olvidamos de los problemas de las “Variables Globales” de PHP), así como configuración de los permisos para evitar intrusiones.
• Modularidad Total de sus componentes: Joomla es como el “Lego”, te dan una base y a partir de ahí lo que necesites
• Gran comunidad de desarrolladores: Hay varios cientos de módulos de buena calidad listos para ser usados
• Diseño: Nos olvidamos de los diseños cuadrados. Si se desea, se puede realizar un diseño de cualquier tipo, incluso utilizando tecnología Web 2.0 (lo que tanto está de moda vamos…)
• Programación: Un programador habitual de PHP no tendrá problema alguno en programar módulos, mambots ó componentes. Una lectura de su documentación y API será suficiente para saber las bases.
• Integración de Componentes actuales: Basándome en el punto anterior, adaptar un software existente para su funcionamiento bajo Joomla será cuestión de poco cambio en muchos casos (siempre y cuando el software ya existente no sea un “montón de basura compilada”).
• Disminución de Tiempos de Desarrollo: Algo imprescindible en estos tiempos de competencia tan brutal. Hablamos de menos de 1 hora para tener una web funcionando en Internet (y aún menos automatizando parte del proceso).

Con más tiempo dedicaré otro post para hablar de la programación bajo Joomla, aunque poco podré aportar a la gran documentación existente.

Manual de Desarrollo: http://help.joomla.org/content/section/12/125/ 

Cuando empezamos a trabajar en ello, decidimos utilizar una base ya conocida y con varios años de funcionamiento, OsCommerce. Se trata de una solución “Open Source“, que ofrecen lista para ser utilizada y empezar una tienda, sin embargo, tiene bastantes carencias cuando hablamos de montar una tienda en territorio español:

• No es intuitivo para los impuestos
• No permite introducir los datos fiscales (DNI/CIF/NIE)
• Falta un sistema de Facturación
• Formas de Envío, Formas de Pago

A día de hoy ya tenemos un sistema casi finalizado, y ahora empieza la etapa de testeo, muy necesaria para evitar problemas posteriores. Estoy orgulloso por lo que estamos terminando, sobre todo el sistema de facturación integrado que estoy terminando de programar (gráficas incluídas).

P.D.: No hay que olvidarlo, tecnología AJAX incluída en el sistema de facturación y gráficas

Toda la info en este foro

Hace meses, por motivos laborales (había que crear un sistema de facturación específico, y nada mejor que las facturas en PDF) me vi “obligado” a empezar a jugar con librerías de generación de PDFs dinámicas. Siempre que puedo, rechazo aquéllas soluciones que requieren instalar módulos en un servidor… ya sabéis, las migraciones son horribles.

Buscando y buscando, encontré una solución que satisface mis necesidades… la FPDF Library; permite la generación de PDFs sin tener ningún módulo en el servidor. Su mayor desventaja es que tiene menor velocidad… pero esto sólo se nota en PDFs de decenas de páginas, vamos, para generar facturas, por ejemplo, es perfecto. Como siempre, y siguiendo mis gustos (por suerte así puedo hacerlo), es específico para PHP.

FPDF es una clase escrita en PHP que permite generar documentos PDF directamente desde PHP, es decir, sin usar la biblioteca PDFlib. La ventaja es que, mientras PDFlib es de pago para usos comerciales, la F de FPDF significa Free (gratis y libre): puede usted usarla para cualquier propósito y modificarla a su gusto para satisfacer sus necesidades.

FPDF tiene otras ventajas: funciones de alto nivel. Esta es una lista de sus principales características:

• Elección de la unidad de medida, formato de página y márgenes
• Gestión de cabeceras y pies de página
• Salto de página automático
• Salto de línea y justificación del texto automáticos
• Admisión de imágenes (JPEG y PNG)
• Colores
• Enlaces
• Admisión de fuentes TrueType, Type1 y codificación
• Compresión de página

Su uso es bastante sencillo para cualquier persona que se mueva con soltura bajo PHP, y la verdad, permite hacer verdaderas “virguerías”. Se trata de una clase creada para ser utilizada sin módulos de terceros, totalmente gratuita, y que puede ser utilizada en cualquier tipo de software, ya sea comercial ó no.

FPDF es freeware (tal y como se afirma al principio del fichero fuente). No hay limitaciones de uso. Puede usarlo libre y gratuitamente en su aplicación (comercial o no), con o sin modificaciones.

Por otro lado, exíste otra clase, que técnicamente utiliza fpdf (un pelín modificado) que permite crear al vuelo PDFs desde ficheros HTML, HTML 2 PDF, aunque la verdad, no es tan automático como dicen… en fin, es para mantener la gracia del juego.

Si queréis ver su resultado, sólo tenéis que comprar un móvil en www.telecomlibre.net, contratar un hosting en www.veliris.com ó porqué no… un diseño web, tienda virtual… bla bla bla (un poquito de publicidad… )

http://www.fpdf.org

http://html2fpdf.sourceforge.net/

Un Saludo,

Carlos