Haciendo enlaces como Twitter, Hash-Bang #! URL's

Posible duplicado:
¿Para qué sirve el shebang / hashbang (#!) En Facebook y las nuevas URL de Twitter?

Me preguntaba cómo Twitter trabaja sus enlaces.

Si miras el código fuente, utilizas los enlaces como / #! / I / connect o / #! / I / discover, pero no tienen una function de JavaScript asociada a ellos como load ('connect') o algo así, y que no requiere una recarga de página. Simplemente cambia el contenido de la página.

Vi esta página, pero luego todos esos files tendrían que existir, y no podrías ir directamente a uno de ellos. Me imagino que en Twitter cada uno de esos files no existe, y que se maneja de algún otro modo. Por favor corrígeme si me equivoco, sin embargo.

¿Hay alguna manera de que pueda replicar este efecto? Si es así, ¿hay un tutorial sobre cómo hacer esto?

Navegación "Hash-Bang" , como a veces se llama, …

http://whatever.com/path/to/#!/some-ajax-state 

… es una solución temporal para un problema temporal que rápidamente se está convirtiendo en un problema, gracias a los estándares modernos de los browseres. Con toda probabilidad, Twitter lo eliminará gradualmente, como Facebook ya está haciendo.

Es la combinación de varios conceptos …

En el pasado, un enlace tenía dos propósitos : cargaba un documento nuevo y / o lo desplazaba hacia abajo a un ancla incrustada como se indica con el hash (#).

 http://whatever.com/script.php#fourth-paragraph 

Cualquier cosa en una URL después de que el hash no se solicitó del server, pero el browser lo buscó en la página. Todo esto todavía funciona bien.

Con la adopción de AJAX , el nuevo contenido podría cargarse en la página actual (ya cargada). Con esta carga dinámica, surgieron varios problemas : 1) no había una URL única para marcar o vincular a este nuevo contenido, 2) la búsqueda nunca lo vería.

Algunas personas inteligentes resolvieron el primer problema utilizando el hash como una especie de reference de "estado" para include en enlaces y marcadores. Después de cargar el documento, el browser lee el hash y ejecuta las requestes AJAX, mostrando la página más sus cambios dynamics en AJAX.

 http://whatever.com/script.php#some-ajax-state 

Esto resolvió el problema de AJAX, pero el problema del motor de búsqueda aún existía . Los motores de búsqueda no cargan páginas y ejecutan Javascript como un browser.

Google al rescate. Google propuso un esquema donde cualquier URL con un hash-bang (#!) En lugar de solo un hash (#) sugeriría al bot de búsqueda que había una URL alternativa para la indexing, que involucraba una variable "_escaped_fragment_", entre otros cosas. Lea sobre esto aquí …

https://developers.google.com/webmasters/ajax-crawling/docs/getting-started

Hoy en día, con la adopción de JavaScript pushstate en la mayoría de los principales browseres, todo esto se está volviendo obsoleto. Con pushstate, a medida que el contenido se carga o cambia dinámicamente, la URL de la página actual se puede modificar sin causar una carga de página. Cuando se desee, esto proporciona una URL real que funciona para marcadores e historial. Los enlaces se pueden hacer como siempre, sin hashes y hash-bangs .

A partir de hoy, si carga Facebook en un browser más antiguo, verá el hash-bangs, pero un browser actual demostrará el uso de pushstate.

Es posible que desee ver más en URL únicas .

Está cargando la página a través de AJAX y parsing el "hash" (los valores que vienen después del "#") para determinar qué página va a cargar. Además, este método se utiliza debido a la naturaleza que las requestes AJAX no countn para el historial del browser, por lo que el "button de retroceso se rompe". Pero el browser sin embargo almacena en la historia los cambios hash.

Usando hashes más el hecho de que puede usar hashes para determinar páginas, puede decir que puede mantener las páginas solicitadas por AJAX "en la historia". Además de eso, las URL hash son solo URL, y son marcadores, incluido el hash, por lo que también puede marcar las páginas solicitadas por AJAX.