Ajax
Ajax: Problema de configuración en apache de Debian para usar UTF-8
Todos los que hemos trabajado en Ajax sabemos el infierno que surge de la codificación de caracteres. Como consejo general, es mejor trabajar todo en UTF-8 y olvidarse de hacer encodes y decodes para arriba y para abajo.
Ahora bien, tengo dos computadores para trabajar, en la clásica formación de desarrollo y producción. El primero, en Gentoo, nunca me daba problemas con el tema de las codificaciones en UTF-8, pero el de producción con Ubuntu, sí. Cada vez que probaba el nicechat instalado en el Ubuntu, el navegador se quedaba pegado en ISO-8859-1. Probé con cambiar el encabezado del html, enviar mensajes de cabecera con el php, pero nada.
Hasta que di con el problema. El apache de Ubuntu viene con la directiva AddDefaultCharset on, que envía una cabecera con el set de codificación, que viene por defecto en ISO-8859-1. Fue cosa de comentar la directiva y, ¡voilá! Todo empezo a funcionar como es debido.
Para los que tengan alojadas sus páginas en servidores externos, es cosa de crear o modificar el archivo .htaccess y agregar la instrucción
AddDefaultCharset off
Revisando en la red, me di cuenta que otros ya se habían percatado del problema, que es genérico a las distro Debian.
Más información:
- Añadir nuevo comentario
- 4032 lecturas
Para nicechat... una consulta
Estimados:
Cómo sé que esto sale en Planeta Código, aprovecho de preguntarles a todos los programadores que andan por ahí.
Ayer, conversando con Juanjo sobre nicechat, me comentó sobre jisp, el formato que tiene Jabber y otros programas de MI para manejar sus íconos. Me pareció una estupenda idea implementarlo y en unos 20 minutos ya tenía una primera implementación del bicho, a través de la escritura de archivos php que correspondan a las especificaciones del jisp.
Ahora bien, mi pregunta va por en que lado establezco el reemplazo, si por el lado del cliente o del servidor. En el primer caso, debo enviar al javascript la lista completa de reemplazos al iniciar la página, y para mensaje el script debería encargarse de hacer los cambios que corresponden. Claro, puede sobrecargar bastate al js, pero se tiene la interesante ventaja de que cada cliente elija que set de íconos quiere utilizar y que el servidor no recibe ningún tipo de sobrecarga.
La segunda alternativa es hacer los cambios en el servidor. Si se habilita la opción, el servidor debe hacer las transformaciones necesarias antes de la salida del texto. Si bien garantiza que las imágenes se verán bien, produce ciertamente una mayor carga en el servidor (el lado más flaco del sistema) y hace necesario "compilar" scripts con las especificaciones, para lograr un rendimiento aceptable.
Yo me estoy inclinando por la versión del lado del cliente, aunque sea un poquito más complicada. Ustedes, ¿que piensan?
- 1 comentario
- 1934 lecturas
Nicechat v0.1.0
La tasa de actualización es buena, ¿no?
Cambie el número de versión, ya que hay un gran cambio en la forma de manejar la identificación del usuario. En las versiones 0.0.x, está se realizaba por una sesiones de PHP, lo que hacía que se compartiera la sesión de trabajo(valga la redundancia) entre todas las ventanas (o pestañas) de un mismo navegador.
Ahora, cada ventana tiene su propia sesión de trabajo, así que se pueden crear tantas identidades y entrar a todos los canales que se quieran. Esto implica usar un poco más la base de datos, por lo que los ping están un poco más largos que antes; tengo que ajustar la base de datos para que funcione mejor.
Además, se incorporaron tres nuevas características:
- Soporte para smileys: Sí, no lo pude resistir. Aparte, que son no más de 5 líneas de código. Por ahora, sólo tengo :), :( y :P, pero no cuesta nada agregar las otras. Los íconos son los de Gaim, por si acaso
- Aparición inmediata de mensaje del propio usuario: esto fue sugerencia de Ignacio. Los mensajes del propio usuario son enviados de inmediato a la consola, y no son considerados al enviar los nuevos mensajes al cliente
- Indicador con la tasa de refresco. ?til para saber que valores son los más adecuados para la configuración de su servidor
Descarga: http://php.apsique.com/files/proyectos/nicechat-0.1.0.tar.gz
Demo: http://php.apsique.com/nicechat
- 5 comentarios
- Leer más
- 2241 lecturas
Nicechat v0.0.2
Después de algunos errores y tirones de pelo, actualicé el pequeño bicho a su versión 0.0.2.
Cambios:
- Indicador de ping y de acciones en curso
- Resolución de vulnerabilidad (no se dieron cuenta? era feroz!)
- Ajustes en los valores por defecto para actualización y timeout.
Nos vemos!
http://php.apsique.com/files/proyectos/nicechat-0.0.2.tar.gz
- Añadir nuevo comentario
- 1820 lecturas
Nicechat: Un agradable chat en Php, Mysql y XmlHttpRequest
Se lo mostré a Christian, y le gustó. Lo pusé en una aplicación del lugar donde trabajo y las chicas se pusieron a chatear como locas.
Así que, nada que hacer. Presentamos en sociedad a nicechat, el chat en php que puede (o no) hacerles la vida más fácil.
Entre sus características se encuentran:
- Pequeño: No más de 20kb de código
- Rápido: En una intranet, fácil hace ping de 60ms, sin ningún tipo de optimización. En internet, los ping pueden llegar a 300ms
- Fácil de instalar: Es cosa de meter el sql en la base de datos, configurar un archivo y comienza a funcionar!
- Fácil de adaptar: El sistema está hecho para que se integre del modo menos instrusivo posible en cualquier tipo de aplicación ya hecha. Hasta creo que sería fácil con smarty :P
- 20 comentarios
- Leer más
- 10419 lecturas
¿Que onda con UTF-8? Sets de caracteres, la web y Ajax
Objetivo
Al finalizar este artículo, el lector, si logra traducir algo de mi verborrea, será capaz de
- Entender de forma bastante vaga que son las codificaciones de caracteres
- Decir, ¡A,ha!, cuando lea ASCII, ISO-8859-1, Unicode y UTF-8
- Entender como maneja el objeto XMLHttpRequest los set de caracteres en Firefox e IE
- Realizar aplicaciones que manejen de modo adecuado las codificaciones y decodificaciones de UTF-8 a ISO-8859-1 en PHP
Dicho esto, pueden leer el texto
- 52 comentarios
- Leer más
- 26966 lecturas
Ajax: Toxic, un nuevo cajón de herramientas para manejar Ajax con PHP5
En Versión cero anuncian la aparición de una nueva herramienta para Ajax (para variar), llamada Toxix
- 3 comentarios
- Leer más
- 3593 lecturas
Disectando XMLHttpRequest: versión alternativa
Un muy buen artículo sobre este extraño objeto:
Recarga de página controlada, por Daniel Rodríguez Herrera en Programación en Castellano
- Añadir nuevo comentario
- 1865 lecturas
Disectando XMLHttpRequest
Intro
Hace mucho, mucho tiempo atrás, comenté sobre los diversos métodos para recoger información desde el servidor sin recargar la página. Ocupé el término RPC vía HTTP para dar cuenta de este fenómeno, pero desde el artículo de Adaptative Path llamado ajax: a new approach to web applications, el nombre Ajax se ha incrustado en el inconsciente colectivo de todos nosotros.
Como bien dice nuestro estimado James, Ajax es un enfoque, más que una tecnología específica, que tiene como antecedente trucos tan sucios como recoger información en iframes escondidos, tal como lo hace mi querido jsrs. Ok, ok, hasta ahora no estoy diciendo nada que no haya dicho, pero sirve de introducción
- 9 comentarios
- Leer más
- 8493 lecturas
Disectando Sajax
Tanto buzz acerca de Ajax por aquí, Ajax por acá, que decidí tomar el toro por las astas y me pusé a buscar por ahí
Como soy un perezoso sin remedio, busque para partir la implementación más breve, que parece ser Sajax. En estos momentos, está en su versión 0.10, la cual se puede ver (para PHP) en esta dirección.
Los conceptos fundamentales son bastante simples
- El lenguaje de servidor se encarga de crear tanto la parte del servidor como la del cliente, o sea, el Javascript necesario
- Las funciones del lado del servidor deben "registrarse", para ser aceptadas por la aplicación
- El javascript generado tiene una parte "estática", que podría incluirse en un sajax.js, digamos, y una parte "dinámica", generada por el propio php. Esta tiene relación con generar funciones "stub", que tienen el mismo nombre de la función del servidor, precedidas por "x_"
- La función a llamar desde javascript tiene el formato
x_funcion(arg1,arg2,...,callback)
Donde callback es una función que recibe el texto generado por la función del servidor
Y eso es todo. Debo reconocer que cumple a cabalidad con el principio KISS.
Como soy un complicado por naturaleza, se me ocurrió de inmediato hacer una versión en javascript independiente, basada en un objecto singleton. La gracia estaría en que el javascript quedaría absolutamente independiente del lenguaje del servidor, pudiendo acceder a cualquier recurso de red con total libertad. A continuación, les muestro la implementación de la clase oSajax en Javascript.
- var oSajax = {
- debug_mode: false,
- request_type: "GET",
- uri: "",
- debug: function (text) {
- if (this.debug_mode) {
- alert("RSD: " + text)
- }
- },
- init: function () {
- this.debug("sajax_init_object() called..")
- var A;
- try {
- A=new ActiveXObject("Msxml2.XMLHTTP");
- } catch (e) {
- try {
- A=new ActiveXObject("Microsoft.XMLHTTP");
- } catch (oc) {
- A=null;
- }
- }
- if(!A && typeof XMLHttpRequest != "undefined") {
- A = new XMLHttpRequest();
- }
- if (!A) {
- this.debug("Could not create connection object.");
- }
- return A;
- },
- do_call: function () {
- var i, x, n;
- var post_data;
- var callback=null;
- var uri = this.uri;
- var al = arguments.length;
- var args=new Array();
- if(!al) {
- alert("Necesito por lo menos un argumento");
- } else {
- func_name = arguments[0];
- if(al>1) {
- callback=arguments[1];
- for(i=2;i<al;i++) {
- args.push(arguments[i]);
- }
- }
- }
- if (this.request_type == "GET") {
- if (uri.indexOf("?") == -1) {
- uri = uri + "?rs=" + escape(func_name);
- } else {
- uri = uri + "&rs=" + escape(func_name);
- }
- for (i = 0; i < args.length; i++) {
- uri = uri + "&rsargs[]=" + escape(args[i]);
- }
- uri = uri + "&rsrnd=" + new Date().getTime();
- post_data = null;
- } else {
- post_data = "rs=" + escape(func_name);
- for (i = 0; i < args.length; i++) {
- post_data = post_data + "&rsargs[]=" + escape(args[i]);
- }
- }
- x = this.init();
- x.open(this.request_type, uri, true);
- if (this.request_type == "POST") {
- x.setRequestHeader("Method", "POST " + uri + " HTTP/1.1");
- x.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
- }
- var self=this;
- x.onreadystatechange = function() {
- if (x.readyState != 4) {
- return;
- }
- self.debug("received " + x.responseText);
- var status;
- var data;
- status = x.responseText.charAt(0);
- data = x.responseText.substring(2);
- if (status == "-") {
- alert("Error: " + data);
- } else if(callback) {
- callback(data);
- }
- }
- x.send(post_data);
- this.debug(func_name + " uri = " + uri + "/post = " + post_data);
- this.debug(func_name + " waiting..");
- delete x;
- }
- }
El script de "servidor", en serv.php
- include "Sajax.php";
- function multiply($x, $y) {
- return $x * $y;
- }
- sajax_init();
- sajax_export("multiply");
- sajax_handle_client_request();
Y el script en html
- <script language="JavaScript" src="sajax.js"></script>
- <html>
- <head>
- <title>Multiplier</title>
- <script>
- function do_multiply_cb(z) {
- document.getElementById("z").value = z;
- }
- function do_multiply() {
- // get the folder name
- var x, y;
- x = document.getElementById("x").value;
- y = document.getElementById("y").value;
- oSajax.uri="serv.php";
- oSajax.debug_mode=true;
- oSajax.do_call("multiply",do_multiply_cb,x,y);
- }
- </script>
- </head>
- <body>
- <input type="text" name="x" id="x" value="2" size="3">
- *
- <input type="text" name="y" id="y" value="3" size="3">
- =
- <input type="text" name="z" id="z" value="" size="3">
- <input type="button" name="check" value="Calculate"
- onclick="do_multiply(); return false;">
- </body>
- </html>
La gracia es que el archivo Sajax.php no se altera para nada y hacemos la implementación del javascript y del php absolutamente independientes una de otra. El servidor podría estar en ruby o en c y el html no se daría ni cuenta....
Para no ser malas personas, incluyo este mismo script a continuación, para que hagan la prueba
* =aquí pueden encontrar el archivo .tgz con los archivos utilizados. La verdad, esto es llegar y llevar :)
- 5 comentarios
- 3021 lecturas

Comentarios recientes
hace 5 días 12 horas
hace 5 días 13 horas
hace 1 semana 22 horas
hace 1 semana 1 día
hace 1 semana 1 día
hace 1 semana 2 días
hace 1 semana 2 días
hace 2 semanas 12 horas
hace 2 semanas 3 días
hace 2 semanas 4 días