You are reading

TiddlyWiki, la alternativa a PHPWiki

Probando wikis para instalar en Jujuy Weblogs (después de mi intento frustado de instalar PHPWiki), me encuentro con TiddlyWiki, un EXCELENTE wiki totalmente hecho en JavaScript. Tienen que probarlo, es una alternativa mas que recomendable para aquellos que no pudimos con PHPWiki, y que no nos sentíamos a gusto con PMWiki.

Para los perdidos, acá vá una definición de Wiki, por la Wikipedia en español:

El término de WikiWiki («wiki wiki» significa «rápido» en la lengua hawaiana) se utiliza en la Wikipedia y en otros muchos sitios de Internet para nombrar una colección de páginas web de hipertexto, cada una de las cuales puede ser visitada y editada por cualquier persona. Una versión web de un wiki también se llama WikiWikiWeb. Se trata de un simple juego de palabras, dado que las iniciales son WWW como en la World Wide Web.

Frecuentemente abreviado como wiki, es una aplicación de informática colaborativa, que permite que documentos web sean creados colectivamente usando un simple esquema de etiquetas y marcas, sin que la revisión del contenido sea necesaria antes de su aceptación para ser publicado.

Creo que estas interfaces hechas totalmente en JavaScript (digamos, sin necesitar demasiado de transacciones del lado del servidor) son la base de las aplicaciones web del futuro (ya tenemos un ejemplo de este tipo de aplicaciones web, con GMail). Por qué ? Simplemente porque se asemejan lo suficiente (respecto a su comportamiento y uso) a cualquier interfase de software no-web, por lo cual, la curva de aprendizaje para los usuarios no se hace tan empinada ni dificil de sobrellevar.

Un ejemplo de la vida real para bajar un poco el concepto: Nosotros usamos como aplicación de webmail a Squirrelmail, un soft open source muy robusto. El otro día, un cliente nos preguntaba, por qué, cuando el iba escribiendo una dirección de correo en el campo “para”, no le iban apareciendo las sugerencias de “autocompletar”, que tiene Outlook para las direcciones de e-mail. Este es un caso muy típico de un usuario que quiere que su aplicación web sea parecida a su aplicación desktop (no encuentro otra palabra para nombrarla).

Creo que con esta generación de JavaScript-like-apps vamos a acortar la diferencia, y de hecho, día a día lo estamos haciendo. GMail fué solo el comienzo.

Comments for this entry

Osvaldo

User

Me parece barbara la recomendacion, yo tambien renegue mucho con la instalacion de phpwiki, sera muy bueno pero la verdad es que es un quilombo para montarlo.
Por otro lado cuando decis:

Creo que estas interfaces hechas totalmente en JavaScript (digamos, sin necesitar demasiado de transacciones del lado del servidor) son la base de las aplicaciones web del futuro

me parece que no es tan asi, fijate que (lamentablemente) no podes usar gmail con todos los exploradores.
Me parece que mientras menos hagas laburar al explorador y mas al servidor es mejor debido a que obtenes mejores resultados, seguridad, rapidez, eficiencia etc. La verdad que es todo un tema no?

Si Osvaldo, la verdad que es todo un tema. Tenes razon lo de que Gmail no anda en todos los navegadores, hace un rato queria entrar con IE5 y no funcaba. Es mas, ellos dijeron que en Safari no andaba (en las primeras versiones de GMail), ahora esta todo de lujo.

Creo que esto se debe a una mala implementacion del modelo DOM en los navegadores (no creo que sea de GMail), aunque estoy convencido, que si pensamos en estandares (ya estamos pensando y migrando hacia CSS + XHTML standards compliant web sites), tambien, en un futuro proximo, podriamos pensar en estandarizar JavaScript a través del modelo DOM de la W3C. Esto se está haciendo, pero no se le dá la bola suficiente, claro, JS siempre fué el malo de la pelicula.

Es solo cuestión de tiempo, la onda HOY es de CSS+XHTML como un primer paso hacia la “estandarizacion”, la onda mañana va a ser tratar de estandarizar todas las tecnologias client-side (como JavaScript).

Respecto a las ventajas de usar scripts server-side … Seguridad ? Tal vez … por ejemplo, si el servidor se cae durante una transacción estas chau, cosa que con JS no sucedería. Rapidez ? Hay algo mas rapido que una operacion JS ? El server no necesita leer nada, todo se hace desde el cliente, luego se transmiten los resultados para su almacenamiento en alguna tablita al server …

En fin, dá para discutirlo. Obvio, esta la posibilidad de que el cliente haya desactivado JS de su navegador, pero bueno, la cosa es asi. Una mezcla entre server-side y client-side (como la de GMail) es lo que se viene … a mi entender …

Otra cosita … pudiste instalar PHPWiki en un Fedora ? Si es así chiflame que me quedé con la leche en el ojo yo !

El JS realmente es necesario, hay situaciones dinámicas que son ineludibles. pero comparto con Osvaldo que el manejo en el lado del cliente tiene tambien sus contras, y con la banda ancha que se hace mas accesible dia a dia (lamentablemente no tanto como debiera)se disminuye esa restriccion favoreciendo al server side.

En fin, de todas formas es bueno que hayan soluciones para cada tecnología, me parece barabaro que los usuarios tengamos apra elegir.

Saludos

siempre es bueno tener un abánico de opciones por donde elegir y optar a la hora del desarrollo de soluciones. server-side, client-side son diferentes soluciones para la misma, como yo tengo conexión dial-up para mi siempre es la mejor solución JS
cuando todos tengamos banda ancha será otra la historia!
salu2!!!!

Leave your comment

Please be polite. You can use these HTML tags: STRONG, A, BLOCKQUOTE, CODE



Copyright © 2004–2010 Rodrigo Galindez. All rights reserved. Hosting by XMundo Networks.

RSS Feed. Proudly powered by Wordpress. Correct at time of going to print.