En el diseño de una página web hay algún momento en el que queremos utilizar cierta fuente para un título o un texto destacado, pero html no dispone de ella. Antiguamente se utilizaban imágenes con el texto que queríamos mostrar, pero actualmente podemos reemplazar el texto “al vuelo” con la reducción de trabajo que ello supone. Una de éstas técnicas es Cufón, basada en javascript nos permite además de reemplazar fuentes, añadir efectos al texto (no disponibles en css2).

Ventajas:

• No necesita plugins instalados en el navegador.
• Es compatible con la mayoría de navegadores del mercado.
• Es rápido. Puede reemplazar grandes téxtos rápidamente.
• Es fácil de instalar (lo vemos ahora mismo).

Instalando Cufón

1. Descarga cufón y añádelo a tu proyecto:
   

   <script src="cufon-yui.js"
type="text/javascript"></script>

2. Convierte a cufón la fuente que quieres utilizar, si tu proyecto es en español no te olvides de los acentos, “eñes”, etc…
3. Añade el .js de la fuente y empieza a utilizar cufón de la siguiente manera:
   

   <script src="cufon-yui.js"
type="text/javascript"></script>

   <script src=”Myriad.font.js”
   type=”text/javascript”></script>

   <script type=”text/javascript”>

   Cufon.replace(‘h1′);

   </script>

4. Disfruta….

Utilizando múltiples fuentes

Puedes utilizar más de una fuente a la vez en tu proyecto. Para ello toma nota de éste ejemplo:

<script src="cufon-yui.js"
type="text/javascript"></script>

<script src=”Helvetica.font.js”
type=”text/javascript”></script>

<script src=”Myriad.font.js”
type=”text/javascript”></script>

<script type=”text/javascript”>

Cufon.replace(‘h1′, { fontFamily: ‘Helvetica’ });

Cufon.replace(‘h2′, { fontFamily: ‘Myriad Pro’ });

</script>

Bueno, esto es lo que pensamos:

1. osCommerce ofrece más funciones  que Prestashop, si bien es a través de contribuciones de terceros. Estas Contribuciones son gratuítas, pero a menudo presentan errores o incompatibilidades entre ellas. No obstante, Prestashop estándar (out-of-the-box) proporciona suficiente funcionalidad para responder a los requerimientos de un gran número de proyectos

2. La flexibilidad de PrestaShop es muy amplia en términos de diseño y distribución de la página (layout). Mediante el mecanismo de los “hooks” se puede posicionar cualquier módulo (carro, fabricantes, monedas, búsqueda, etc) en cualquier posición. Los límites son la imaginación y creatividad.

3. SEF y SEO son muy superiores en PrestaShop, y además vienen en la distribución estándar. Hemos encontrado que son incluso superiores a componentes SEO de pago para osCommerce, que también está limitado en la optimización de Meta-tags.

4. Soporte multi-idioma. PrestaShop contiene un editor integrado para modificar el texto de la tienda en los diferentes idiomas. La carga de los ficheros de idioma está más optimizada en PrestaShop que en osCommerce, Zen Cart, CRE Loaded y osCMax .

5. Los aspectos de Seguridad son muy superiores en PrestaShop. No como osCommerce, que aún usa el peligroso “register_globals ON”.

6. Compatible con PHP 5 y MySQL 5, que proporcionan mayor rendimiento y seguridad. Es mejor construir una Tienda nueva compatible con PHP 5 y MySQL 5, ya que PHP 4 y MySQL 4 estarán obsoletos y sin soporte muy pronto. osCommerce no es totalmente compatible con PHP 5 y MySQL 5.

7. El Caché de PrestaShop mejora el rendimiento de la Tienda en términos de reducir el tiempo de carga. osCommerce no dispone de esta característica.

8. En PrestaShop es posible crear tantos contenidos (páginas personalizadas) como se desee, incluyendo HTML, imágenes y ortros componentes. En osCommerce sólo se puede conseguir algo parecido a través de una contribución.

9. PrestaShop tiene suficiente recorrido futuro para admitir mejoras. Sin embargo osCommerce ha alcanzado su punto final de madurez tecnológica, y no queda mucho espacio para mejoras futuras. PrestaShop, ideado para la Web 2.0, se basa una tecnología acorde con el estado del arte, y puede admitir muchos tipos de ampliaciones y mejoras.

10. osCommerce tiene un gran número de diseños para hacer plantillas sobre ellos. Para PrestaShop es bastante fácil hacer Temas nuevos (el diseño está separado del motor de comercio electrónico), y de hecho cada vez hay más en el mercado.

Un modelo puede tener diversas vistas, cada una con su correspondiente controlador. Un ejemplo clásico es el de la información de una base de datos, que se puede presentar de diversas formas: diagrama de tarta, de barras, tabular, etc. Veamos cada componente.

Modelo

Es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comprar un número de unidades negativo, o calculando los totales e impuestos del carrito de compra. Esto quiere decir que aquí se operan los datos y las reglas de negocio asociadas al sistema,
incluyendo el análisis sintáctico y el procesamiento de los datos de entrada y
de los datos de salida.

El Modelo es el responsable de:

• Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
• Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: “Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor”.
• Lleva un registro de las vistas y controladores del sistema.
• Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero batch que actualiza los datos, un temporizador que desencadena una inserción, etc.). Un ejemplo de MVC con un modelo pasivo (aquel que no notifica cambios en los datos) es la navegación web, que responde a las entradas del usuario, pero no detecta los cambios en datos del servidor.

Vista

Este presenta el Modelo, usualmente la interfaz de usuario. La vista es la capa de la aplicación que ve el usuario en un formato adecuado para interactuar, en otras palabras, es nuestra interfase grafica.

Las vistas son responsables de:

• Recibir datos del modelo y los muestra al usuario.
• Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
• Pueden dar el servicio de “Actualización()”, para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes).

Controlador

El Controlador es la capa que controla todo lo que puede realizar nuestra aplicación. Responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Está compuesto por acciones que se representan con funciones en una clase. Por ejemplo, yo tengo mi controlador llamado “Clientes”, y este controlador puede realizar las acciones “Crear”,”Editar”,”Listar” entre otras.

El controlador es responsable de:

• Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
• Contiene reglas de gestión de eventos, del tipo “SI Evento Z, entonces Acción W”. Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método “Actualizar()”. Una petición al modelo puede ser “Obtener_tiempo_de_entrega( nueva_orden_de_venta )”.

El diagrama de secuencia

Pasos:

1. El usuario introduce el evento.
2. El Controlador recibe el evento y lo traduce en una petición al Modelo (aunque también puede llamar directamente a la vista).
3. El modelo (si es necesario) llama a la vista para su actualización.
4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.

Ventajas y Desventajas

La popularidad de este diseño se debe mas que todo a que es mucho mas fácil organizar aplicaciones grandes.

Las ventajas

• Clara separación entre interfaz, lógica de negocio y de presentación, que además provoca parte de las ventajas siguientes.
• Sencillez para crear distintas representaciones de los mismos datos.
• Facilidad para la realización de pruebas unitarias de los componentes, así como de aplicar desarrollo guiado por pruebas (TDD).
• Reutilización de los componentes.
• Simplicidad en el mantenimiento de los sistemas.
• Facilidad para desarrollar prototipos rápidos.
• Los desarrollos suelen ser más escalables.

Las desventajas:

• Tener que ceñirse a una estructura predefinida, lo que a veces puede incrementar la complejidad del sistema. Hay problemas que son más difíciles de resolver respetando el patrón MVC.
• La curva de aprendizaje para los nuevos desarrolladores se estima mayor que la de modelos más simples como Webforms.
• La distribución de componentes obliga a crear y mantener un mayor número de ficheros.

Ejemplo

Bien, pero esto ¿cómo se implementa? Existe una pequeña dificultad: la mayor parte de las herramientas de desarrollo incorporan en las clases de la vista gran parte o todo el procesamiento de eventos. Con lo que el controlador queda semioculto dentro de la vista. A pesar de ello, podemos acercarnos bastante al patrón.

Modelo

Un ejemplo de la vida real de un Modelo seria una clase llamada Cliente, la cual tiene las mismas propiedades de una tabla cliente en mi base de datos

Controlador

Un Controlador seria el Controlador Cliente, generalmente las clases Controladoras llevan el sufijo “Controlador”, así que en nuestro caso se llamaría ClientesControlador.

El controlador llevaría las acciones que nosotros podemos realizar en un cliente como por ejemplo, agregar, borrar, modificar, agregar orden, etc.

Vista

La Vista es el mas fácil de entender, simplemente es nuestra pagina html. A través de la acción del Controlador especificamos a que vista queremos enviar el resultado de la acción del Controlador. En algunos casos es necesario pasar información a la Vista desde el Controlador, esto se logra fácilmente en el código de la acción.

¿Por qué es este enfoque mucho más rápido?

El motor de caché de Smarty realiza un gran trabajo compilando las plantillas en el momento adecuado, y esto produce un aumento sustancial de la velocidad comparado con la recompilación de la plantilla con cada petición de página.

No obstante, incluso cuando Smarty sirve páginas de su caché, hay una cantidad de trabajo extra añadido a cada petición comparado con el servidor web sirviendo directamente la página desde el caché. Esto es porque  PHP debe llamarse, la librería Smarty se debe incluir, y una pequeña cantidad de procesos deben ejecutarse dentro de Smarty antes de que la página en caché sea servida.

¿Es esta técnica de caché adecuada para cualquier situación?

En casos en los que la vida del caché debe ser muy corta debido a cambios frecuentes en los datos que deben mostrarse, el enfoque de este artículo puede resultar inviable. No obstante, en estos casos puede ser todavía posible un proceso forzado que borre el caché cuando los datos cambian, en lugar del trabajo extra añadido de comprobar si ha habido cambios en cada solicitud de página. Esta aproximación de borrado forzado del caché reduce el coste al valor más bajo posible, así que si el rendimiento es de vital importancia, tiene todo el sentido ensayar esta técnica.

Cuando los cambios en los datos ocurren infrecuentemente, una combinación de vaciar el caché en intervalos programados más un método para forzar manualmente la recompilación de páginas específicas es adecuada, y un compromiso que vale la pena para aumentar el rendimiento.

Notas sobre la Implementación

Ya que Smarty es una librería muy flexible, cada implementación es única. Por tanto, en lugar de intentar abordar la cuestión de cómo implementar el caché en Lighttpd,  explicaremos una forma de hacerlo que resultó adecuada en la práctiica.

Esta era la configuración de Lighttpd para el sitio web antes de implementar el caché. Tenía unas pocas reglas de re-escritura de URLs, de forma que las peticiones de ficheros (htm|html) se pasaban directamente a index.php. Este fichero actúa como un manejador para determinar la plantilla Smarty que debe cargarse, permitiendo además el uso de URLs amigables.

Y después de implementar el caché, esta es la configuración del servidor Lighttpd:

Más abajo está el código de rewrite.lua (referenciado más arriba en la configuración de Lighttpd), que implementa lighttpd mod_magnet para manejar las reglas de re-escritura de URLs. Comprueba el sistema de ficheros para determinar si existe un fichero en caché, y, si es así, sirve ese fichero. En otro caso, re-escribe hacia el manejador index.php, de forma que Smarty puede generar un nuevo fichero para el caché.

La variable cache_path en el script rewrite.lua almacena la carpeta del caché de Smarty ( $smarty->cache_dir ), además de $smarty->cache_id (en este caso es blank (vacío); asegúrese de agregarlo a la variable cache_path como una subcarpeta del cache_dir de Smarty correspondiente a su instalación)

cache_path = "/var/www/site/tmp"
cache_code = "compile"
-- construir la página y guardarla en el caché del sistema de ficheros
function cache_gen()
	lighty.env["physical.path"]  = lighty.env["physical.doc-root"] .. "/index.php"
	lighty.env["uri.query"] = "p=" .. string.gsub(lighty.env["uri.path"], "\.(htm|html)$", "")
	--print ("CACHE: " .. lighty.env["uri.query"])
end
-- cargar la copia desde al caché del sistema de ficheros
function cache_load()
	lighty.env["physical.path"] = cache_path .. lighty.env["uri.path"]
	--print ("LOAD: " .. cache_path .. lighty.env["uri.path"])
end
-- añadir el fichero index si se solicita un listado del directorio
if(lighty.env["uri.path"] == "" or string.find(lighty.env["uri.path"], "/", -1)) then
	lighty.env["uri.path"] = lighty.env["uri.path"] .. "index.html"
end
-- procesar las peticiones htm|html
if(string.find(lighty.env["uri.path"], "htm", -4)) then
	exists = lighty.stat(cache_path .. lighty.env["uri.path"])
	cache_code_passed = false
	if(lighty.env["uri.query"] ) then
		cache_code_passed = string.find(lighty.env["uri.query"], cache_code)
	end
	if(exists and not cache_code_passed) then
		action = cache_load()
	else
		action = cache_gen()
	end
end

En este punto, Lighttpd está re-escribiendo todas las solicitudes y enviándolas al manejador index.php ya que no encuentra una imagen caché en la carpeta cache_path. Ahora hay que trabajar con el manejador index.php de forma que Smarty guarde los ficheros HTML compilados en el cache_path definido en rewrite.lua. Para hacer esto, podemos escribir una función personalizada manejadora del caché para Smarty, e incluirla en el fichero index.php. Hasta aquí, la implementación de Smarty se parece a:

<?php
require "../includes/smarty/Smarty.class.php";
$smarty = new Smarty;
$smarty->template_dir 	= 'templates';
$smarty->compile_dir  	= 'compile';
$smarty->cache_dir    	= '/var/www/site/tmp';
$smarty->caching      	= true;
$smarty->force_compile	= true;
$smarty->compile_id     = '';
$smarty->cache_handler_func = 'server_rewrite_cache_handler';
function server_rewrite_cache_handler($action, &$smarty_obj, &$cache_content, $tpl_file=null, $cache_id=null, $compile_id=null, $exp_time=null)
{
	$cache_file = $smarty_obj->cache_dir . '/' . $compile_id . $cache_id;
	if(!is_file($cache_file)) {
		$base_file =  basename($cache_file);
		$base_dir = dirname($cache_file);
		if(!is_dir($base_dir)) mkdir($base_dir, 0777, true);
	}
    switch ($action) {
        case 'read':
        	if(!is_file($cache_file)) return false; else return true;
            break;
        case 'write':
        	return file_put_contents($cache_file, $cache_content);
            break;
        case 'clear':
        	return @unlink($cache_file);
            break;
        default:
            return false;
            break;
    }
}
$_p = $_REQUEST['p']; // detectar el path del fichero solicitado para guardar la copia en caché con el nombre y path correctos
$page = ''; // lógica aquí para detectar la plantilla Smarty correcta que debe mostrarse
$smarty->display($page, $_p);
?>

Lo principal aquí es que el caché está habilitado, cada petición recompila la plantilla, el compile_id es blank (vacío), y el cache_dir coincide con lo que está puesto en cache_path (en rewrite.lua).

La funcción server_rewrite_cache_handler() sobre-escribe la lógica por defecto de Smarty para leer/escribir/vaciar el caché de forma que el fichero se guarda en la estructura de directorio correcta que coincide con la solicitud que fue re-escrita desde Lighttpd.

La última cosa es deshabilitar algunas líneas de código en el fichero smarty/internals/core.write_cache_file.php, ya que por defecto Smarty añade algunos datos serializados a la cabecera de los datos del caché que pasa a nuestra función personalizada para manejar el caché. Los cambios se muestran más abajo, y ocurren sobre las líneas 65 y 66 del fichero core.write_cache_file.php.

Esto es todo. Debería experimentar una drástica mejora en la velocidad y rendimiento del servidor en este punto.

Para muchos de nosotros resulta fácil programar un script con PHP que realice estas tareas, pero en muchos servidores no se permite ejecutar estos scripts directamente desde la línea de comandos.

La solución a este problema consiste en utilizar CURL. Este paquete viene incorporado en la mayoría de las distribuciones Linux.

CURL es una herramienta para transferencia de ficheros con sintaxis URL, que envía la salida por defecto a la pantalla. Podemos hacer la siguiente prueba:

# curl http://www.google.es

También puede reenviar la salida y guardarla en un fichero

# curl http://www.google.es > google.htm

CURL soporta diferentes protocolos: FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, DICT, FILE, LDAP y algunos más. Además se instala una librería con un conjunto de funciones que pueden ser usadas desde PHP.

Siguiendo con nuestro caso, podemos ejecutar ahora un script PHP desde la línea de comandos, simplemente escribiendo esto:

# curl http://localhost/miscript.php

Supongamos que vamos a ejecutar un script que envía los email de nuestro boletín de correo llamado boletin.php pero éste se encuentra alojado en una carpeta protegida de nuestro servidor web. En este caso es necesario pasarle a CURL el usuario y contraseña para acceder al directorio protegido.

# curl -u username:password http://localhost/protegido/boletin.php

Para programar en el cron de nuestro servidor esta tarea y que sea ejecutada automáticamente de forma periódica debemos conocer la ruta completa donde esta instalado el curl que habitualmente suele ser en /usr/bin.

A continuación editar el fichero de tareas de cron (por ejemplo con el comando crontab -e), y añadimos esta línea:

30 4 * * * /usr/bin/curl -u username:password  http://localhost/protegido/boletin.php

Esto hará que todos los días a las 4:30 de la madrugada se ejecute el script boletin.php de manera automática. Normalmente las empresas de hosting ofrecen opciones dentro del Panel de Gestión para administrar cómodamente las tareas programadas. Consulte con su proveedor habitual.

Hay que tener en cuenta el timeout de las peticiones HTTP. Si un proceso tarda mucho debido a su complejidad, el servidor Web finaliza la ejecución de la tarea por tiempo excedido. En entornos de producción no es recomendable ampliar el tiempo de ejecución en el servidor web.

El crontab envía generalmente un correo cuando el script produce una salida. Si no se desea esta información, basta redirigir la salida estándar y la de error añadiendo al final de los comandos: 1>/dev/null 2>/dev/null

Más información sobre la programación de tareas en la ayuda (# man crontab).

Pero, ¿por qué tendríamos que elegir precisamente Smarty? La respuesta es muy sencilla: este sistema es, en definitiva, el más rápido.

Algunos enlaces para empezar:

• www.maestrosdelweb.com/editorial/que-es-smarty/
• www.maestrosdelweb.com/editorial/smarty-plantillas/
• www.maestrosdelweb.com/editorial/smarty-a-nivel-avanzado/
• www.programacion.com/tutorial/phpsol_smarty/
• www.smarty.net
• devzone.zend.com/article/1238

…y no olvidar:

Work Smarter, not Harder!

Como dicen en su sitio web …

“El Plugin jQuery Cycle es un carrusel de imágenes que soporta muchos tipos de efectos de transición. Permite pause-on-hover, auto-stop, auto-fit, before/after callbacks, click triggers y mucho más.

… ¡y es muy sencillo de instalar! …

Añadir el javascript …

Añadir las imágenes …

Y añadir el código jQuery …

Esta es la idea básica. Para más detalles, características avanzadas y ejemplos, consultar: http://malsup.com/jquery/cycle/.

(la pregunta  “¿cuál es mejor?” debe reemplazarse urgentemente por la anterior!!)

Muchos analistas independientes sugieren que  Magento se ajusta mejor a proyectos (y empresas) de tamaño “medio-grande”, y Prestashop a proyectos de tamaño “pequeño-medio”. Esta etiqueta ha sido refutada en varias ocasiones por los mismos fundadores de PrestaShop, argumentando que debe ser detallada y explicada.

La distinción entre las dos herramientas se basa esencialmente en cuatro criterios:

1.- Riqueza funcional: Magento ofrece más funciones en la versión estándar (out-of-the-box) que Prestashop, particularmente en términos de flexibilidad de la configuración (opciones de productos, costes de envío), comparación de productos, búsqueda avanzada, gestión de varias tiendas (esta característica, como otras, está “prevista” en Prestashop, pero probablemente en un plazo considerable debido a su complejidad).
 
2.- Curva de aprendizaje: en el reverso de la moneda, el back office (zona de administración de la tienda) de Magento es menos intuitiva, y su estructura, muy técnica (quizá más asumible a largo plazo), requiere conocimientos técnicos más especializados para cualquier ajuste.
 
3.- Magento facilita la comunicación con aplicaciones de terceros (ERP, CRM, etc.) mediante un API (Application Programming Interface) y Webservices integrados de forma nativa.
 
4.- Recursos del Servidor: Prestashop no produce mucha carga en el servidor, y un posting compartido es más que suficiente (o sea, unas decenas de euros al año), mientras que Magento parece comportarse mejor en un servidor dedicado (unas decenas de euros al mes, o más) y requiere una optimización técnica cuidadosa para asegurar el tiempo de respuesta  correcto (este aspecto es regularmente mejorado por el equipo de desarrollo de Magento)

No obstante, sobre los puntos  1 y 3:

a.- Prestashop estándar (out-of-the-box) proporciona suficiente funcionalidad para responder a los requerimientos para el éxito de un gran número de proyectos.

b.- Es bastante factible desarrollar módulos personalizados para intercambio de datos (existen algunos, otros en desarrollo).

Si el estudio de viabilidad del proyecto de comercio electrónico no muestra diferencias significativas entre la versión estándar y los requerimientos a corto / medio / largo plazo, es perfectamente factible lanzar un proyecto ambicioso de tienda online con Prestashop.

Por contra, si se parte de un presupuesto modesto, elegir Magento tiene el riesgo de lastrar las probabilidades de éxito del proyecto con el peso sustancial de los trabajos técnicos y una curva de aprendizaja más elevada.

En el terreno del software, está claro: el que puede hacer lo más no es necesariamente el mejor posicionado para hacer lo poco. Y forzándole a hacer lo poco, probablemente será a costa de un trabajo (y coste) mayor.

Si intenta comenzar con un archivo de Excel con letras acentuadas, y guardado en formato CSV con separador “punto y coma”, podrá ver que las letras acentuadas se convierten en caracteres irreconocibles cuando se importan.

El problema es que con Excel, no se puede elegir el juego de caracteres.

Una solución es la dada por 6ma : a través de OpenOffice, que permite especificar la forma de guardar el archivo .csv en el momento de guardarlo.

Hemos probado guardar con formato ISO 8859-1, pero aún los mismos problemas. Por el contrario, todo fue bien guardando como UTF-8.

También es perfectamente posible codificar los caracteres en UTF-8 con Microsoft Excel. Basta con escribir una macro que realiza la codificación.

El ejemplo a continuación permite la codificación, decodificación y pruebas.

Del mismo modo, es fácil escribir otra macro que automáticamente generará formato CSV con la codificación que se quiera, directamente desde Excel.