Sigo en mi evangelización de CodeIgniter, y en este caso se trata de un mini tutoria que explica cómo crear un carrito de la compra usando la librería Shopping Chart Class que ofrece CodeIgniter. Quizás sea mejor utilizar aplicaciones específicas para crear tiendas, pero en algunos casos no nos queda otra que implementarlo nosotros mismos.
Este es un ejemplo raro de uso de WordPress, pero el otro día una persona lo preguntaba en el foro de soporte de WordPress. El usuario tenía los posts geolocalizados (latitud/longitud), supongo con postmetas correspondientes.
Para poder realizar este tipo de búsquedas es necesario usar MySQL procedures, claro que no todos los hosting lo permiten:
CREATE PROCEDURE geodist (IN mylat decimal(18,12), IN mylon decimal(18,12), IN dist float)
BEGIN
declare lon1 float;
declare lon2 float;
declare lat1 float;
declare lat2 float;
set lon1 = mylon-dist/abs(cos(radians(mylat))*69);
set lon2 = mylon+dist/abs(cos(radians(mylat))*69);
set lat1 = mylat-(dist/69);
set lat2 = mylat+(dist/69);
SELECT p.*, 3956 * 2 * ASIN(SQRT( POWER(SIN((mylat -lat.meta_value) * pi()/180 / 2), 2) +COS(mylat * pi()/180) * COS(lat.meta_value * pi()/180) *POWER(SIN((mylon - lon.meta_value) * pi()/180 / 2), 2) )) as distance FROM wp_posts as p, wp_postmeta lat, wp_postmeta lon WHERE p.ID = lat.post_id and lat.meta_key = 'latitude' and p.ID = lon.post_id and lon.meta_key = 'longitude' and lon.meta_value between lon1 and lon2 and lat.meta_value between lat1 and lat2
and post_status = 'publish'
having distance < dist ORDER BY Distance;
END
Una vez creado el procedure deberemos llamarlo para obtener los resultados:
No me apasiona especialmente realizar aplicaciones para Facebook, pero cuando no te queda otra, es mejor no complicarse la existencia y usar un buen framework como CodeIgniter (claro, que algunas aplicaciones si se realizan sin más tampoco pasa nada).
Para aquellos que quieran realizar aplicaciones en Facebook usando CodeIgniter le puede venir bien estas dos guías y dos librerías. Tanto las guías hablan de lo mismo, y las librerías son para Facebook-Connect (pero en una de ellas la explican paso a paso).
No suele ser algo común que necesitemos un corrector ortográfico en nuestras aplicaciones web, pero por si alguien lo necesita, puede que este tutorial le venga bien.
El método es sencillo, obtenemos una lista de palabras en español (o el idioma que queramos) y la frecuencia con la que aparecen, para ello es bueno usar un libro o varios, obtener las palabras y calcular la frecuencia. Después, mediante la distancia Levenshtein, que nos devuelve el numero de letras que tenemos que modificar, insertar o borrar para que dos palabras sean las mismas, hacemos una lista de las palabras que los usuarios utilicen en nuestra aplicación (el buscador por ejemplo) y las palabras del diccionario, guardando solo aquellas relaciones que tengan una distancia 1 o 2.
Usando la lista con la relación entre palabras, cuando un usuario introduzca una palabra equivocada, le mostraremos las palabras que tengan una distancia 1 y si no hay, las que tengan una distancia 2.
Google, si mal no creo, a parte de este método lo que hace es controlar que palabras introducen los usuarios que no obtienen datos y las palabras que introduce después y que si obtienen datos.
Cada día suenan más las bases de datos clave-valor, y entre ellas Tokyo Tyrant, por lo que no nos vendrá mal hacer uso de la librería PECL para ella, lástima que sea PECL. PHP Tokyo Tyrant
Ahora viene la parte más complicada, y digo complicada porque sinceramente he tenido que mirar el código porque algo me fallaba cuando seguía lo que decía la documentación.
El nombre del fichero JSON tiene el siguiente formato [dominio de traducción]-[idioma]-[handler del fichero].json, total nada.
Dominio será el que usemos para traducir, en el ejemplo sería mi-plugin:
__( 'Hola que tal', 'mi-plugin' );
Idioma es el código del idioma, en este caso es_ES
Y por último el handler del fichero es el primer parámetro que usamos en wp_enqueue_script
Lo podemos ver todo en un ejemplo final:
wp_enqueue_script(
'mi-plugin-handler', // El handler mencionado anteriormente
$blocks_script, // Nuestro path
[
'wp-i18n', // De referenciar al menos a wp-i18n
],
);
wp_set_script_translations( 'mi-plugin-handler, 'mi-plugin', plugin_dir_path( __FILE__ ) . 'languages' );
Comienzo: Symfony tiene mucha documentación y gente por detrás desarrollando y ayudando, algo de lo que anda un poco corto Zend.
Testing: Symfony viene con tareas de testing por lÃnea de comandos y genera una clase vacÃa para ello al crear un controlador. Mientras que Zend no ofrece soporte para testing.
Plantillas: Zend tiene un sistema de plantillas un poco verde al que hay que hacerle algunos hacks para realizar algunas cosas. Symfony, al contrario, su sistema de plantillas es muy maduro, al cual le puedes añadir módulos.
Plugins: más de lo mismo, Symfony es extensible, Zend no.
Módulos de bases de datos: Zend usa ActiveRecord, mientras que en Simfony le puedes añadir el motor que desees, incluso Zend_Db.
Asà es, la clase de carro de compra te puede salvar en algún apuro donde se necesite implementar una tienda online sin necesidad de utilizar alguna de las avanzadas tiendas online disponibles en la web.
Saludos!
Hola Julian, interesante el blog que tienes 🙂
Saludos
TodavÃa no tuve que hacer ningún carrito desde que salió esta clase, pero me guardo este tutorial para cuando llegue el momento 🙂
Asà es, la clase de carro de compra te puede salvar en algún apuro donde se necesite implementar una tienda online sin necesidad de utilizar alguna de las avanzadas tiendas online disponibles en la web.
Saludos!
Hola Julian, interesante el blog que tienes 🙂
Saludos
TodavÃa no tuve que hacer ningún carrito desde que salió esta clase, pero me guardo este tutorial para cuando llegue el momento 🙂