Ver la Versión Completa : Uso de diferentes tipos de URLs en aplicaciones Web
Hola,
Estoy un poco intrigado con las URLs que pueden verse en algunos sitios Web y que son más o menos así, por ejemplo:
http://www.ejemplo.com/login/
http://www.ejemplo.com/usuario/panel_control/
http://www.ejemplo.com/busqueda/cadena1+cadena2
Me explico. Generalmente en las pruebas que voy haciendo con PHP suelo utilizar URLs de este tipo, por ejemplo:
http://www.ejemplo.com/login.php
http://www.ejemplo.com/busqueda.php?cadena=cadena1
http://www.ejemplo.com/usuario/logout.php
Entonces, como me placen más las URLs como las que menciono en primer lugar, pienso que pueden conseguirse más o menos de este modo:
http://www.ejemplo.com/login/
... Siempre que en el directorio "login" exista un archivo "index.php",... u otro archivo "predeterminado" de algún modo mediante algún archivo ".htacess" (ni siquiera sé si lo escribo bien, apenas sé que existen).
Pero, no sé porqué me da la sensación de que no se trata de tener archivos "index.php" "predeterminados" en los directorios de nuestra aplicación, esto es, de crear directorios como "panel_control", "busquedas", "usuario", ¿no es esto más complicado que no utilizar los directorios y "llamar" directamente a los "Script" PHP oportunos?
Por otro lado, ya he dicho que me placen más las URLs que muestro en primer lugar, pero, ¿será una cuestión de gustos nada más? ¿Acaso se gana algo ocultando los "Script" PHP de la URL, o, simplemente, haciéndolo de modo que las URLs sean como las que muestro en primer lugar? ¿Alguna ventaja inherente al hacerlo así?
Añadiría que me vengo dando cuenta de este tipo de URLs que menciono de un tiempo a esta parte, no demasiado. Un ejemplo de sitio Web (además muy popular) que hace uso de esta "técnica" y del que me acuerdo ahora mismo es del.icio.us (http://del.icio.us/popular/).
¿A alguien se le ocurre algo o sabe algo de esto que he comentado? Gracias de antemano y disculpad el rollo. Si no se entiende algo me lo decís a ver si podemos hacer algo. ;)
Emilio
04-05-2006, 10:38:37
Pienso que es totalmente indistinto hacer uso de cualquiera de las formas que indicas, realmente no veo ningún motivo evidente para recomendar una u otra práctica, ambas son buenas.
Si un sitio web es grande, es logico separar las cosas por directorios, esto no hace necesariamente las cosas mas complicadas sino al contrario.
Es mas sencillo tener organizados los scripts por funcionalidad en distintos directorios que tener cientos de archivos todos mezclados en un mismo sitio.
Independientemente de esto ultimo, sí se puede utilizar el sistema que comentas sin necesidad de tener directorios, tampoco es necesario tener archivos de script separados. Esto lo hacen varios gestores de contenidos.
El truco esta en usar un unico script php por ejemplo index.php que recibira todas las peticiones de archivos no encontrados "Not found" y este script debe analizar la url recibida y ejecutar el codigo php necesario
Normalmente se pone en el .htccess una directiva como:
ErrorDocument 404 /index.php
Esto hace que, por ejemplo, cuando alguien pide algo como:
http://www.ejemplo.com/usuario/nuevo
Al no existir la url realmente, el servidor web da un error 404 no encontrado, y ejecuta automaticamente el index.php de la raiz de la pagina web, ahora es este script el que se tiene que encargar de analizar la url recibida y realizar la accion necesaria, cargando el script apropiado o lo que sea.
El gestor de contenido drupal utiliza este sistema, es una caracteristica que le llaman "clean_urls" , urls limpias: www.drupal.org
Una ventaja del uso de urls limpias es que es mucho mas facil para los buscadores indexar las paginas de un sistio web, normalmente indexan muchas mas paginas. Por ejemplo si utilizamos una sintaxis del tipo siguiente para determinadas busquedas:
http://www.ejemplo.es/buscar/titulo/titanic
http://www.ejemplo.es/buscar/titulo/superman
http://www.ejemplo.es/buscar/titulo/spawn
Desde el punto de vista de los buscadores parecen distintas paginas estaticas, y normalmente las indexara todas.
Otra ventaja de tener un index.php centralizado se refiere al control de la web, al tener un unico punto de entrada se puede realizar operaciones que afecten a toda la pagina web de una forma sencilla modificando unicamente el script de entrada, por ejemplo añadir calculos estadisticas, visitas etc , cambios de apariencia globales, control de accesos para denegar la entrada a toda la web a determinados usuarios o ips, y todo esto sin tener que incluir nada en todos y cada uno de los scripts de la web.
Saludos
Miguel
reevil
04-05-2006, 12:29:39
otra cosa que hay que tomar en cuenta es la seguridad, al mandar direcciones de este tipo : www.pagina.com/login.php?pass=password
es claro que podriamos tener algun problemilla
en google hay mucha informacion sobre los metodos post y get para envio de variables en php, excelente para no enviar urls de ese tipo
saludos
Hola,
Bueno. Primero de todo, muchas gracias por responder a mi inquietud.
Pienso que es totalmente indistinto hacer uso de cualquiera de las formas que indicas, realmente no veo ningún motivo evidente para recomendar una u otra práctica, ambas son buenas.
A mí es que me llamaba la atención ver algunos sitios Web que emplean el tipo de URLs a que me he referido. Por supuesto que otros sitios Web también muy curiosos no hacen uso de dicha técnica, a lo menos no tan fundamentalmente como dice el compañero Mick que se hace en el gestor de contenidos Drupal (http://drupal.org/). Por ejemplo, en WordPress (http://www.wordpress.org/) (otro gestor de contenidos) se hace "mitad y mitad" (podría decirse) y WordPress[/URL] me parece un estupendo trabajo y ahí están sus resultados, que se pueden ver.
Lo que sí habría que dilucidar es si se trata de algo más que una moda o una forma de lograr URLs más "limpias" o "agradables", porque, de ser así, tal vez habría que tomarse la molestia de aprender un poco más sobre el tema.
Si un sitio web es grande, es logico separar las cosas por directorios, esto no hace necesariamente las cosas mas complicadas sino al contrario.
Totalmente de acuerdo. De hecho es una práctica que utilizo no solamente en PHP, pero con Delphi, con cualquier lenguaje o entorno, procuro que los proyectos que llevo a cabo hagan uso y se aprovechen de los beneficios que conlleva separar las cosas y tenerlas por eso mismo un poco más ordenadas.
Es mas sencillo tener organizados los scripts por funcionalidad en distintos directorios que tener cientos de archivos todos mezclados en un mismo sitio.
Cierto, cierto. Aunque también es cierto que con PHP tengo algún que otro problema, seguramente por mi inexperiencia con el lenguaje y hasta la plataforma (cliente/servidor, si se puede decir así). En el sentido de que he visto ocasiones en que prácticamente me he visto obligado a añadir más archivos en un solo directorio (el raíz, generalmente) de los que yo deseara. Pero, ya digo, esto debe ser más bien inexperiencia mía, falta de recursos y salidas, entre otras cosas.
El truco esta en usar un unico script php por ejemplo index.php que recibira todas las peticiones de archivos no encontrados "Not found" y este script debe analizar la url recibida y ejecutar el codigo php necesario
Pues, así, a bote pronto, no sé si es porque la idea no se me ha ocurrido a mí (suele sucederme) o por qué será, pero, me parece un poco una "chapucilla", eso de que el mecanismo utilizado por el Servidor Web para advertir de archivos no encontrados se utilize para propósitos internos de la aplicación Web, nada menos que para su "sistema de navegación o URLs", dicho mal y pronto.
Sin embargo, también podría extrañarme de mi extrañamiento, porque cosas así ya he visto algunas, y porque tal vez la idea de hacerlo así y los resultados funcionen perfectamente.
El gestor de contenido drupal utiliza este sistema, es una caracteristica que le llaman "clean_urls" , urls limpias: [URL="http://www.drupal.org/"]www.drupal.org (http://www.wordpress.org/)
Es estupendo que respondieras Mick, porque, efectivamente, has dado información precisa. Ya descargé (mientras escribía esto) Drupal y después quisiera echarle un vistazo en general (que no lo he hecho nunca) y de forma particular a ese "index.php" tan curioso que deben de tener. ;)
Una ventaja del uso de urls limpias es que es mucho mas facil para los buscadores indexar las paginas de un sistio web, normalmente indexan muchas mas paginas. Por ejemplo si utilizamos una sintaxis del tipo siguiente para determinadas busquedas:
http://www.ejemplo.es/buscar/titulo/titanic
http://www.ejemplo.es/buscar/titulo/superman
http://www.ejemplo.es/buscar/titulo/spawn
Desde el punto de vista de los buscadores parecen distintas paginas estaticas, y normalmente las indexara todas.
Una ventaja nada desdeñable, supongo. Yo con HTML no he tenido problemas, afortunadamente, mis páginas solían aparecer en Google: procuraba por mi parte mantenerlas "limpias", con código fuente válido y validado, en fin. Pero, con PHP las cosas cambian, las páginas se generan dinámicamente, y aquí me pierdo yo un poco. Así que, como digo, la ventaja que mencionas no parece nada desdeñable.
Otra ventaja de tener un index.php centralizado se refiere al control de la web, al tener un unico punto de entrada se puede realizar operaciones que afecten a toda la pagina web de una forma sencilla modificando unicamente el script de entrada, por ejemplo añadir calculos estadisticas, visitas etc , cambios de apariencia globales, control de accesos para denegar la entrada a toda la web a determinados usuarios o ips, y todo esto sin tener que incluir nada en todos y cada uno de los scripts de la web.
Resalto parte del párrafo anterior porque era, precisamente, lo que iba a comentar a continuación. Independientemente de la URL, siempre se terminaría en un punto de entrada (siempre, siempre, depende, a lo mejor para algunas URLs conviene que tengan propio punto de entrada). Casi estoy deseando echar un vistazo al "index.php" de Drupal, porque me parece interesante y curioso todo este asunto.
otra cosa que hay que tomar en cuenta es la seguridad, al mandar direcciones de este tipo : www.pagina.com/login.php?pass=password (http://www.pagina.com/login.php?pass=password)
es claro que podriamos tener algun problemilla
Otra cosa que no es moco de pavo. Esas URLs que dices son un poco feas, aunque no diré yo que no puedan utilizarse las URLs para pasar parámetros a ciertos Script, no es eso. Como todo, bien utilizado el recurso... Empero, es cierto que me da un poco de grima el encontrarme con URLs de ese tipo, como si intuitivamente supiera que no son la mejor forma de hacer las cosas. Bueno. El método "POST", en lugar de "GET" tal vez puede de entrada ofrecernos mejores resultados en estos temas.
Bueno. Que muchas gracias a todos. Que habéis sido muy amables respondiendo y que voy a ver si puedo sacar algo y aun algos en claro de todo lo que habéis dicho. Que tengáis un buen día y una buena noche también. Gracias otra vez. ;)
roman
04-05-2006, 17:37:45
Respecto al uso de index.php, me gustaría comentar que muchas personas opinan que este tipo de front controllers no es adecuado y uno de los argumentos que dan es el de que el servidor http es ya un controlador que se encarga de dirigir las peticiones a las distintas páginas. Yo no estoy ni a favor ni en contra necesariamente de eso. También, dicho desde mi ignorancia, creo que es importante entender que no todo es una cuestión meramente de gustos. Por ejemplo, el método POST y el método GET, no son, o no deberían ser intercambiables; cada uno está pensado y diseñado para un fin específico. Hay algo que llaman REST, que parece ser importante leer antes de adentrarse en una moda de urls. Como digo, yo no es que esté muy al tanto de estos temas pero los comento porque son cosas con las que me he encontrado últimamente al buscar este tipo de temas.
// Saludos
Bueno, pues me he decidido meterme a esta conversación para dar algunos puntos de vista al respecto, aunque no estoy 100% seguro si no me he perdido al leerlo.
Siempre que he visto este tipo de URLs me ha entrado mucha curiosidad, como esta URL que nos dio dechttp://www.ejemplo.com/busqueda/cadena1+cadena2 Había pensado en que método utilizaban para identificar la cadena de busqueda, luego me engontre con esta funcion de php que analiza la url de entrada y la divide en partes:
<?php
print_r(parse_url($url));
?> A esta función le pasé la url obtenida de la variable $_SERVER["REQUEST_URI"]
<?php
$VUrl = parse_url($_SERVER["REQUEST_URI"]);
?> Que en el caso de la url "http://www.ejemplo.com/buscar/cadena" me quedaria un arreglo de la siguiente manera:
Array
(
[scheme] => http
[host] => www.ejemplo.com
[path] => /buscar/cadena
)
Luego de esto, puedo utilizar la cadena que se encuentra en "$VUrl['path']" para dividirla utilizando la función explode y obtener otro arreglo con los datos que esta contiene
<?php
$VPath = explode("/",$VUrl['path']);
?> de este modo el arreglo que obtengo es el siguiente:
Array
(
[0] => buscar
[1] => cadena
)
ahora ya puedo hacer la llamada al script que corresponde, que en este caso es es script de busqueda que llamaremos buscar.php que se encuentra en el directorio ./http/
<?php
include "./http/$VPath[0].php";
?> y pues como ya sabemos que la posicion 1 de larreglo $VPath contenine la frase a buscar, lo especificamos en el script y listo.
Esto es lo que estoy utilizando actualmente (desde hace una semana :p) y supongo que podría mejorarse, si a alguien se le ocurre una mejor idea, que la ponga aquí y la examinamos:D.
Actualmente todos los scripts los tengo en el directorio ./http/ de la carpeta raíz, para asi no tener un monton de archivos en la raiz del sitio y que estos estén mas ordenados.
<?='Saludos'?>
Emilio
04-05-2006, 23:40:14
Mick, creo que no entiendo bien todo lo que dices, a ver si me puede explicar con más amplitud las dudas que tengo sobre algunas cosas que nos comentas.
Si un sitio web es grande, es logico separar las cosas por directorios, esto no hace necesariamente las cosas mas complicadas sino al contrario.
Es mas sencillo tener organizados los scripts por funcionalidad en distintos directorios que tener cientos de archivos todos mezclados en un mismo sitio.
Totalmente de acuerdo.
Independientemente de esto ultimo, sí se puede utilizar el sistema que comentas sin necesidad de tener directorios, tampoco es necesario tener archivos de script separados. Esto lo hacen varios gestores de contenidos.
El truco esta en usar un unico script php por ejemplo index.php que recibira todas las peticiones de archivos no encontrados "Not found" y este script debe analizar la url recibida y ejecutar el codigo php necesario
Normalmente se pone en el .htccess una directiva como:
ErrorDocument 404 /index.php
Esto hace que, por ejemplo, cuando alguien pide algo como:
http://www.ejemplo.com/usuario/nuevo
Al no existir la url realmente, el servidor web da un error 404 no encontrado, y ejecuta automaticamente el index.php de la raiz de la pagina web, ahora es este script el que se tiene que encargar de analizar la url recibida y realizar la accion necesaria, cargando el script apropiado o lo que sea.
El gestor de contenido drupal utiliza este sistema, es una caracteristica que le llaman "clean_urls" , urls limpias: www.drupal.org (http://www.drupal.org)
Entiendo que si se accede a una url no válida haya algo que lo gestione y se lo haga saber al visitante, por ejemplo http://www.clubdelphi.com/url-no-valida te muestra una página avisando del error, pero que tiene eso que ver con la forma de crear la url válidas de tu sitio?
Una ventaja del uso de urls limpias es que es mucho mas facil para los buscadores indexar las paginas de un sistio web, normalmente indexan muchas mas paginas. Por ejemplo si utilizamos una sintaxis del tipo siguiente para determinadas busquedas:
http://www.ejemplo.es/buscar/titulo/titanic
http://www.ejemplo.es/buscar/titulo/superman
http://www.ejemplo.es/buscar/titulo/spawn
Desde el punto de vista de los buscadores parecen distintas paginas estaticas, y normalmente las indexara todas.
Esto ya si que no lo entiendo.
Si a un buscador le pones en lugar de lo que dices
http://www.ejemplo.es/buscar.php?titulo=titanic (http://www.ejemplo.es/buscar/titulo/titanic)
http://www.ejemplo.es/buscar.php?titulo=superman (http://www.ejemplo.es/buscar/titulo/superman)
http://www.ejemplo.es/buscar.php?titulo=spawn (http://www.ejemplo.es/buscar/titulo/spawn)
también lo indexará como tres páginas ¿entonces cual es la ventaja?
Otra ventaja de tener un index.php centralizado se refiere al control de la web, al tener un unico punto de entrada se puede realizar operaciones que afecten a toda la pagina web de una forma sencilla modificando unicamente el script de entrada, por ejemplo añadir calculos estadisticas, visitas etc , cambios de apariencia globales, control de accesos para denegar la entrada a toda la web a determinados usuarios o ips, y todo esto sin tener que incluir nada en todos y cada uno de los scripts de la web.
Pues no me resultan muy convincentes esos argumentos, el uso de includes, te permiten todo lo que dices y además la ventaja de tener cada cosa en el fichero y directorio que corresponde, no obstante si hay algo que he pasado por alto para centralizarlo todo en un index.php me gustaría que me lo aclarases.
Emilio
04-05-2006, 23:49:21
Siempre que he visto este tipo de URLs me ha entrado mucha curiosidad, como esta URL que nos dio dec
http://www.ejemplo.com/busqueda/cadena1+cadena2
¿no es más limpio http://www.ejemplo.com/busqueda.php?cadena=algo?
No le veo ventajas a lo otro y realmente me gustaría saber cuales son.
Si a un buscador le pones en lugar de lo que dices
http://www.ejemplo.es/buscar.php?titulo=titanic (http://www.ejemplo.es/buscar/titulo/titanic)
http://www.ejemplo.es/buscar.php?titulo=superman (http://www.ejemplo.es/buscar/titulo/superman)
http://www.ejemplo.es/buscar.php?titulo=spawn (http://www.ejemplo.es/buscar/titulo/spawn)
también lo indexará como tres páginas ¿entonces cual es la ventaja?
con respecto a esto emilio, si tienes la sigueinte url
http://www.ejemplo.com/temas.php?tarea=ver&id=1
que seria una url en donde los valores posibles de la variable $tarea puedan ser ver, crear y editar, luego en id colocas el tema a ver o editar, la verdad es que si los indexan los buscadores, pero uno de los problemas que causa (digo de los problemas porque no se si es el único o hay mas, además me he enterado por terceros) es con el caracter "&", pues se supone que algunos robots-spiders pueden ignorarlo, mismo caso se dá con los sitemaps de google que detectan como url no válida todas aquellas que tienen este caracter. (no me meto a hablar mas del tema porque la verdad que la mayor parte de el la desconozco).
Pero con lo otro que dices:
¿no es más limpio http://www.ejemplo.com/busqueda.php?cadena=algo?
No le veo ventajas a lo otro y realmente me gustaría saber cuales son.
Lo que yo le veo a esto es que no todo usuario de la aplicación web conoce de estas tecnologías y que significado tiene el que sea .php por ejemplo o este signo "?" (Yo hasta hace algun tiempo lo desconocia:D) y es más facil para los usuarios de la aplicación si únicamente tenemos URLs represantando directorios (aunque estos sean ficticios) porque ellos conoceran mas de esto que de poner ?tema=3245.
Saludos.
mamcx
05-05-2006, 00:38:10
Es bueno ver este tipo de temas por aqui... MUY raro de ver entre desarrolladores netos ;)
Lo de la URLs como lo mencionas de hecho es algo brutalmente importante. Imaginate que de hecho, no muy conocido, las URLS estan basados en un estandar, como este:
http://www.w3.org/Provider/Style/URI.html.es
En la movida hacia la construccion en sitios Web estandares, hay varios frentes:
1- El diseño como tal (que ya mucho estan moviendo a uso de CSS)
2- El reconocimiento de otros navegadores, no solo web(como el usado por personas invidentes)
3- El mejor manejo del contenido
4- La mejor estructuracion de los sitios (URLs no solo limpias sino utiles!)
5- El movimiento a formato de consumo diferentes a paginas html (ej: rss)
y otros temas y subtemas que hacen de construir un sitio web con todos los jugetes un verdadero reto...
Sin embargo, ya que estoy metido de lleno en este tema realmente hay muchos beneficios.
Un buen sistema de URLs, no solo limpias sino con sentido ayuda de forma importante a un buen posicionamiento en los buscadores.
El punto es este: Los buscadores tienen que usar tecnicas para darle un puntaje a un sitio.
Por ejemplo, como sable Google que el clubdelphi maneja buenos chistes? No sabe. Google es verdaderamente estupido, como todos los programas en existencia. Pero se pueden inferir cosas, como la popularidad de la pagina, o en este caso, que tan habil es quien opera un sitio.
Sitio con URLS alocadas: Quien lo opera no es muy habil. De pronto no es tan buen sitio
Sitio con URLS limpias: Tiene chistes malisimos, pero hacer eso implica un peludo que sabe como es la movida actual, mejor puntaje.
Y tonterias como estas... eso se llama SEO...
Hola Mamcx, ccreo que has tocado el punto exacto de este problema, ahora espero que no te molesto, tomaré nota de lo que has dicho y a ponerlo en práctica.
Saludos.
roman
05-05-2006, 01:03:05
Disculpa mi ignorancia, ¿cuál es el punto exacto del problema? Yo de verdad ya no entiendo. En estos foros de vBulletin, los url son "sucios", según colijo de su nomenclatura; más sin embargo tengo entendido que están bastante bien indizados por google.
:confused:
// Saludos
Disculpa mi ignorancia, ¿cuál es el punto exacto del problema? Yo de verdad ya no entiendo. En estos foros de vBulletin, los url son "sucios", según colijo de su nomenclatura; más sin embargo tengo entendido que están bastante bien indizados por google.
Si te das cuenta, vBulletin no utiliza el caracter "&" en ninguna de las urls, en cambio usa nombres diferentes de archivos, el ejemplo que yo ponia:
http://www.ejemplo.com/tema.php?tarea=ver&tema=1
lo hace vBulletin de la siguiente manera
http://www.clubdelphi.com/foros/showtrhead.php?p=1234
algo muy distinto y que puede no causar problemas para los spiders.
Ahora, al haber dicho:
...ocado el punto exacto de este problema...
me referia a la pregunta que hace emilio
No le veo ventajas a lo otro y realmente me gustaría saber cuales son.
Saludos
roman
05-05-2006, 01:36:05
Si te das cuenta, vBulletin no utiliza el caracter "&" en ninguna de las urls
¡Ah caray! ¿Y ésta
http://www.clubdelphi.com/foros/showpost.php?p=135347&postcount=14&highlight=vbulletin
:confused:
// Saludos
¡Ah caray! ¿Y ésta
http://www.clubdelphi.com/foros/showpost.php?p=135347&postcount=14&highlight=vbulletin
en el caso de esta url, al igual que
http://clubdelphi.com/foros/newreply.php?do=newreply&p=135351
No son urls que interese tanto indexar en los buscadores(desde mi punto de vista, claro está).
La URL que has puesto, comparandola con esta:
http://www.clubdelphi.com/foros/showpost.php?p=135347 (http://www.clubdelphi.com/foros/showpost.php?p=135347&postcount=14&highlight=vbulletin)
Muestran el mismo tema, con la única diferencia que resalta la palabra "vBulletin", algo que en mi opinion no es del todo necesario indexar en un buscador, o si:confused:.
Saludos.
Edito:
No son las únicas URLs así en vBulletin, pero si te das cuenta, estas URLs están en una escala menor con respecto a la importancia en indexación, porque ¿de que sirve que indexes un enlace que te lleve a editar un tema?, en algún caso me pasó eso con otro sistema de Foros e incluse me permitia editar y guardar los cambios (al parecer el lema de la SEGURIDAD no era de importancia en este:D)
roman
05-05-2006, 07:47:34
con la única diferencia que resalta la palabra "vBulletin", algo que en mi opinion no es del todo necesario indexar en un buscador, o si:confused:.
No hombre, claro que no. El punto es que no todo es indizar, y otros parámetros tienen otros propósitos útiles, como el de resaltar una palabra en este caso. No me queda claro como pasar estos parámetros "extra" en el caso de url "limpias". Algo como showpost/134567/highlight/vbulletin como que no me convence. Reitero que yo desconozco estos temas pero me gustará entender más las razones de este tipo de urls.
// Saludos
Hola,
Fijémonos por ejemplo en lo que hacen en del.icio.us (http://del.icio.us/) al respecto, a ver si puede servirnos de algo a todos en general, y a mí en particular, para añadir a la explicación que con mejor o peor fortuna he tratado de hacer de aquello que me intrigaba, tal como digo más arriba.
Entrada a la Web:
http://del.icio.us/
"Submit" del formulario "Discover favorites":
http://del.icio.us/search/?all=delphi+components
Vuelta a la portada
http://del.icio.us/
Clic en "Login":
http://del.icio.us/login
"Submit" del formulario de "login" (con datos incorrectos):
http://del.icio.us/login *
* Se muestra un mensaje de error
"Submit" del formulario de "login" (con datos correctos):
http://del.icio.us/dec *
* Donde "usuario" es nuestro "login" en la página Web
"Profile" de un usuario:
http://del.icio.us/settings/dec/profile
Enlaces de un usuario (del.licio.us guarda enlaces, entre otras cosas):
http://del.icio.us/dec
"Inbox" de un usuario:
http://del.icio.us/inbox/dec
Enlaces de un usuario guardados por más usuarios:
http://del.icio.us/for/dec
"LogOut" de un usuario:
http://del.icio.us/logout
Registro de un usuario (Pasos 1, 2 y 3):
http://del.icio.us/register
http://del.icio.us/register?step2
http://del.icio.us/register?step3
Apartado de ayuda de la Web:
http://del.icio.us/help/
Algunos subapartados de ayuda de la Web:
http://del.icio.us/about
http://del.icio.us/help/uses
http://del.icio.us/help/navigation
http://del.icio.us/help/firefox/search
Añadir un enlace a nuestra cuenta de usuario (paso 0, 1, 2):
(Se solicita una Url)
http://del.icio.us/post/
(Se solicita una descripción, notas y etiquetas para la URL)
http://del.icio.us/dec?url=http%3A%2F%2Fwww.clubdelphi.com&submit=save&jump=no
(Añadido el enlace, volvemos a nuestra página de usuario)
http://del.icio.us/dec
Navegando entre etiquetas (los enlaces se clasifican con ellas):
(Viendo la etiqueta delphi)
http://del.icio.us/dec/delphi
(Viendo la etiqueta foros)
http://del.icio.us/dec/foros
No sé. Merece la pena darse una vuelta uno por del.icio.us (http://del.icio.us/), porque, evidentemente, no es cuestión de ver unas cuantas URLs que tal vez puedan dar una idea o servir de ejemplo o valer para dilucidar lo que tratamos en este Hilo: digo que en del.icio.us hay otras cosas interesantes. Pero, además realacionadas con cierto uso de las URLs, que me parecen prácticas para el usuario, más que para el programador, diría yo.
Por ejemplo, créense una cuenta de usuario. Ya empezarán a ver cosas tan curiosas como que habrán de confirmar su cuenta mediante correo electrónico, empero, podrán mientras tanto (no sé por cuánto tiempo ni si con algún límite) utilizar su cuenta de usuario, añadir enlaces, editarlos, buscarlos, etc. Pero, esto no tiene mucho que ver con lo que tratamos.
Una cosa que podría tener que ver y que me llama la atención es cómo puedes pasar de ver los enlaces de una determinada etiqueta a ver los de otra. En la parte superior izquierda de su página de usuario en del.icio.us encontrarán lo que parece una dirección URL, incluso quiere parecerlo, y se ve tal que así (con una fuente destacada) a modo de cabecera de la página en cuestión:
del.icio.us/dec/|etiqueta|
Donde "|etiqueta|" es en realidad un "inputbox" HTML, es decir, puede uno escribir en esa casilla, por ejemplo, "delphi", y luego de pulsar la tecla "ENTER" estaremos viendo los enlaces que tenemos guardados con la etiqueta "delphi".
Bueno. Disculpad por el rollo. No era mi intención aburrir a nadie, os lo prometo. ;)
El punto es que no todo es indizar, y otros parámetros tienen otros propósitos útiles, como el de resaltar una palabra en este caso. No me queda claro como pasar estos parámetros "extra" en el caso de url "limpias". Algo como showpost/134567/highlight/vbulletin como que no me convence. Reitero que yo desconozco estos temas pero me gustará entender más las razones de este tipo de urls. Bueno, empiezo por decirte que yo no coozco del todo este tema y estoy casi seguro de que en algo me estoy equivocando, me he atrevido a participar en este tema, porque es algo que a mi tambien me interesa comprender, me he estado metiendo mas al Desarrollo Web que al Desarrollo de Aplicaciones de Escritorio.
También quiero aclarar que en cuanto a la indexación de la que tanto he hablado, es porque me he enterado de que el utilizar el caracter "&" puede que algunos spiders no la tomen, pero en ningún momento he dicho que no se deban utilizar estas urls. Yo em cambio, he estado utilizando url's de esta forma:
http://www.ejemplo.com/contenido/artículos.html,ver=1,tema=2 (http://www.ejemplo.com/contenido/art%C3%ADculos.html,ver=1,tema=2)
Tampoco es una url limpia, pero me ha funcionado, lo que hago es convertir la cadena en un arreglo, separándo esta por las ",". Luego creo las variables de acuerdo al nombre con que las muestro en la url (Bueno, pa que hablar mas de esto si apenas si yo me entiendo)
Veamos el caso de wikipedia (http://es.wikipedia.org).
Cuando buscas algún tema, te darás cuenta que la url que muestra parece que fuera como que tiene organizado el contenido por directorios, ejemplo de ellos:
http://es.wikipedia.org/wiki/Php
donde Php es el tema a buscar, pero demonos cuenta también que utiliza URLs como esta:
http://es.wikipedia.org/w/index.php?title=PHP&action=edit§ion=1
Donde está pasando parámetros de la forma común y corriente.
Con esto no quiero decir que es necesario u obligatorio que utilices un solo tipo de urls, tampoco que debas usar ambas.
Me parece interesante este (http://www.w3.org/Provider/Style/URI.html.es) enlace que nos ha dejado mamcx y me permito citar parte de lo que ahi he leido:
Se tiene la loca idea de que las páginas producidas por scripts tienen que estar localizadas en un área "cgibin" o "cgi". Esto demuestra el mecanismo con el que estás haciendo funcionar tu servidor. Tú cambias el mecanismo (incluso manteniendo el mismo contenido) y ¡ay, todas tus URI cambian!. Y mas abajo ponen estas urls como ejemplo:
http://www.nsf.gov/cgi-bin/getpub?nsf9814
http://www.nsf.gov/pubs/1998/nsf9814/nsf9814.htm
Definitivamente yo me inclino por la segunda url, es la forma de urls que todo navegante conoce, mientras que la primera, a algunos los dejará pensando en por que una url tan complicada. Además como dice Emmanuelle en este tema:
Esto demuestra el mecanismo con el que estás haciendo funcionar tu servidor. Lo que me parece no seria del todo conveniente si queremos hacer nuestro sitio mas seguro.
Bueno, espero no haber aburrido a ninguno y que me perdonen por cada error que he cometido :D.
Saludos.
mamcx
05-05-2006, 17:21:47
Precisamente.
Una url de forma Cliente?Esto=1&Aquello=2
PUEDE que invoque una accion dinamica. Como crear una cuenta.
Ahora imagina a los spider navegando la pagina y !puff! "clikean" esa URL. Y se van a crear una cuenta... y son varios spider en varias pasadas, y le dan submit al rollo, y devuelve error y se queda en un ciclo...
Ese es el problema que tiene un spider: Que hacer con las URLS? Invocan acciones dinamicas o estaticas?
En cambio:
Cliente/Esto/Aquello
Luce como algo ESTATICO.
Fijate que la mayoria de los sitios web que usan funciones (internas) realmente presentan contenido estatico. O sea, se pudieran haber hecho a mano y quedarian igual.
Por ejemplo, el inicio, los faqs, la info de los productos, etc... realmente pueden presentarse en forma estatica.
No es tanto que hayan Urls "limpias" sino Urls con un sentido y proposito claro.
roman
05-05-2006, 17:45:11
Una url de forma Cliente?Esto=1&Aquello=2
PUEDE que invoque una accion dinamica. Como crear una cuenta.
Pues justamente, es lo que no queda claro. Porque entonces parece que el problema es en el uso que le demos a las formas regulares de urls. Una petición GET no debería estar haciéndola de POST. La url (petición GET) debe representar un documento en la web, esto es, algo tangible, no una acción.
// Saludos
Emilio
05-05-2006, 19:58:54
Yo creo que aquí se están mezclando los usuarios y los buscadores.
Empezando por los usuarios, no encuentro lógico hacer algo para que les parezca menos complicado (ufff, que monstruosidad acabo de decir), bien, me refiero a que hay que abolir los malos hábitos, es de todos los usuarios conocido que una url lleva tres w delante, cosa totalmente falsa, www es un subdominio igual que cualquier otro, por ejemplo http://neftali.clubdelphi.com sería una url totalmente válida pero que ocurre con ello, que los usuarios tienden a pensar que debe ser http://www.neftali.clubdelphi.com y que hacemos, pues que para tener un subdominio realmente tienes que crear dos, uno para el que realmente quieres tener y otro para usuarios con conceptos erroneos, y que hacemos realmente con ello, alimentar su error.
¿Qué quiero decir con esto? sencillamente que si un usuario tiene que teclear la url http://www.clubdelphi.com/fichero.php?parametro1=valor&otro=otrovalor creo que le estamos haciendo un favor, para que continuar engañándole con carpetitas?
En cuanto a los buscadores, ellos saben muy bien y si no lo saben vaya buscador será, desmenuzar url y sus parámetros, está claro que el primer parámetro es el más importante para el buscador, no obstante por supuesto no omite los segundos parametros, vease un ejemplo en esta búsqueda en google (http://www.google.es/search?hl=es&rls=GGLJ%2CGGLJ%3A2006-14%2CGGLJ%3Aen&q=site%3Aclubdelphi.com+highlight&btnG=B%C3%BAsqueda&meta=).
Después de este extenso hilo que ni dec imaginaba que daría para tanto cuando lo inicio, me quedo con el mal sabor de boca al no haber realmente escuchado una buena razón por la cual debo hacer uso de otro tipo de url.
En fin, igual el hilo sigue y todavía sacamos algo en claro.
mamcx
05-05-2006, 21:18:35
Obviamente que un argumento del tipo "si no lo hacemos asi nos morimos" no va a haber, y menos en tonterias informaticas...
Pero ya que de tonterias informaticas vivimos pues...
Yo creo que aquí se están mezclando los usuarios y los buscadores
Ni tanto. Recuerda que un buscador, como google, esta enfocado hacia los usuarios.
Ponte en las zapatillas de un ingeniero de Google o MSN. Tiene que usar formas indirectas para evaluar una pagina.
¿Tiene buenos chistes?. No. Los buscadores no saben reirse. Paila por ese lado
¿Tiene argumentos logicos?. No. La logica de un ordenador no es la de un humano. Tampoco se puede
¿La fotos son bonitas?. No. No saben que es bonito
Nada de eso sirve. Pero si sirve:
¿Cumple con estandares? Si. Eso se puede chequear. Indirectamente se deduce un mejor diseñador/programador web, lo que implica una empresa contratante mas enfocada
¿Tiene buena distribucion de textos?. Eso tambien sirve
¿Buen balance de imagenes/animaciones/textos? Eso sirve
¿Es una pagina popular (ej: PageRank)? Muy util
¿USA URLS ESTATICAS? Si. Urls estaticas indica *indirectamente* que el contenido esta hecho para - humanos -. Las urls son intuitivas, mas cortas, son mas abstractas y menos riesgos de links muertos o invalidos. Sitios mas enfocado hacia el usuario. Urls dinamicas implica aplicaciones que pueden o no tener efectos colaterales y no ser indexables. No es malo tener URLS asi, pero el contenido en un sitio es lo #1. Sin texto indexable, el sitios es como muerto.
Mejor dicho, los buscadores, los navegadores de texto, para invidentes, etc... son ciegos sin texto: NO VEN NADA.
Importa lo de la indexacion?
Por eso dije que este tipo de temas es raro entre desarrolladores netos. No estan pensando en forma de marketing o publicidad. La forma como este hecha un sitio tiene efectos significativos en las evaluaciones, ranking y posicionamiento entre buscadores.
Siendo todo igual, un sitio que usa estandares + urls estaticas obtendra un mayor posicionamiento = mayor visitas = mas popularidad = mas ventas o mayor difusion =mayor posicionamiento = mayor visitas = mas populariodad =...
Por otro lado, existen fuertes motivaciones para los desarrolladores netos. Si no lo creen, miren el estallido de Ruby On Rails para que vean como podria ser la cosa.
Basicamente? Las Urls estaticas (no me gusta eso de limpias o sucias, confunden el proposito) mapean de lo lindo a una arquitectura MVC.
De hecho, estoy haciendo en Delphi (mejor dicho, prototipando) un CMS (administrador de contenido) que incorpore estos asuntos y muchos mas, inspirado por Ruby on Rails, Textile, TextPattern, Web 2.0 y en ultimas una recoleccion exhaustiva de lo mejor de lo mejor en estos temas...
Espero que pueda darle oxigeno a este animal... y sacarlo pronto ;) (si no muero en el intento, les estoy avisando)
roman
05-05-2006, 21:33:20
Las Urls estaticas (no me gusta eso de limpias o sucias, confunden el proposito) mapean de lo lindo a una arquitectura MVC
¿Podrías profundizar en esto? No alcanzo a ver qué tiene que ver una cosa con la otra.
// Saludos
Parece que el tema se ha enfocado principalmente en hablar sobre la apariencia o la conveniencia del uso de un tipo de urls u otras.
Seguramente un termino medio sea lo mas correcto, realmente no conozco ningun sistema que use url limpias en todo porque en muchos casos no es lo mas adecuado, por ejemplo, navegando por cualquier web hecha en drupal veremos urls mixtas, del tipo:
http://drupal.org/forum/37?page=7
En el caso de drupal la utilizacion de las URLs limpias es mas bien un efecto secundario y no un fin en si mismo, el codigo de gestor de contenidos no sabe siquiera que existan ese tipo de urls (a excepcion de la forma de generar los link que devuelve).
Las Urls normales de drupal son asi:
http://drupal.org/index.php?q=forum/37&page=7
Tecleando esto en el navegador web se mostrara la pagina igualmente.
Realmente es una regla de reescritura del servidor web de apache (definida en el .htaccess) la que hace que funcionen, es el propio servidor web el que convierte la url limpia en una url mas sucia que es la que le llega al gestor de contenidos.
Con todo esto lo que pretendo dar a entender es que, en casos como la utilizacion de determinados engines web, se usan URLs limpias simplemente porque se puede hacer sin ningun coste adicional, no es una caracteristica especial que sea costosa de programar, basta simplemente añadir un par de lineas de configuracion al Apache (esto solo es cierto al 99%) y voila ya tenemos las URLs limpias. Y ante esta tesitura, sabiendo que no tiene ningun coste, y si comparamos las dos formas de urls:
http://drupal.org/index.php?q=forum/37&page=7
http://drupal.org/forum/37?page=7
No me cabe duda de que la segunda opcion sera la elegida por el 99.999% de los desarrolladores y usuarios que utilicen este gestor de contenidos (Quizas Emilio seal 0.0001% que no ;) ).
Otro tema interesante que ha planteado Emilio como consecuencia de la explicacion de la forma de procesar las urls, es "el uso de un engine centralizado" vs "uso de scripts separados", esto tambien daria para una buena charla, pero es demasiado tarde hoy.
Saludos
Miguel
Hola,
Sobre REST (Representational State Transfer) encontré un documento de Paul Reinheimer: Simple Web Services: REST (http://cluesheet.com/lectures/REST.pdf) (PDF) que me parece muy curioso e interesante. Por cierto que lo encontré en la Web[/URL] [URL="http://cluesheet.com/"]Cluesheet - Tips for PHP Developers (http://cluesheet.com/) cuyo contenido tampoco parece estar nada mal.
Emilio
06-05-2006, 12:03:08
si comparamos las dos formas de urls:
http://drupal.org/index.php?q=forum/37&page=7
http://drupal.org/forum/37?page=7
No me cabe duda de que la segunda opcion sera la elegida por el 99.999% de los desarrolladores y usuarios que utilicen este gestor de contenidos (Quizas Emilio seal 0.0001% que no ;) ).
Me siento como el dentista que recomienda chicles con azucar :D
En realidad ese dentista es un tío inteligente que mira por su negocio.
Pues me temo que ni siquiera me quedo en ese supuesto 0.0001%, me gusta más la de toda la vida.
http://www.clubdelphi.com/foros/showthread.php?t=31285&page=2
Puede parecer que intento llevar la contraria, incluso a mi llega a parecérmelo con este hilo, pero es que no veo ninguna ventaja por más que me esfuerzo en ello y nadie dice algo concreto para hacerme salir del supuesto lado oscuro en que me encuentro.
Perberos
06-05-2006, 14:14:15
A mi al principio me gustaba ver cosas como:
http://www.localhost.com/?mostrame=algo&bueno=con+toda+la+letra
porque le daba un aire de complicado y dificil de interpretar a simple vista.
pero como es costumbre mia, yo miro a lo estandar, y a lo nuevo o revolucionario.
pero me quedo con lo estandar :P
sobre todo, cuando uno escribe extensos codigos. y no lo hace muy estructurado que digamos.
y a la hora del host. epa, ¿como que el apache no lo puedo configurar para que no me tire error 404?
¿ensima es php4? ¿y yo que tengo algunas funciones del php5? ¿como que el php no tiene pear? &%$#$% con tu host y toda tu &%$% y #@$% familia...
en conclucion, tengo que escribir
http://www.localhost.com/index.php?mostrame=algo&decente=true
aunque es lindo escribir cosas como:
info.php?guide / info.php?guide:12 / info.php?contact:email
pero eso depende del gusto de cada uno y la finalidad, no les parece?
roman
06-05-2006, 18:47:30
De pronto vuelvo a leer esta frase de Emilio.
Yo creo que aquí se están mezclando los usuarios y los buscadores.
Como que ciertamente aquí se han mezclado ambos. La verdad sea dicha, al menos a mi, como usuario, me tienen sin cuidado las url de los sitios que visito. Me parece que los argumentos debiera enfocarse en todo caso al desarrollador y la conveniencia del uso de url "limpias" como aquella que menciona mamcx y que aun no me queda claro.
// Saludos
Hola,
La verdad sea dicha, al menos a mi, como usuario, me tienen sin cuidado las url de los sitios que visito. Me parece que los argumentos debiera enfocarse en todo caso al desarrollador y la conveniencia del uso de url "limpias" como aquella que menciona mamcx y que aun no me queda claro.
Ahí discrepo, aunque sólo sea para que se vea que puede haber divisiones. Yo me vengo fijando en las URLs de los sitios Web desde hace años, incluso antes de saber qué cosa eran las URLs las intuía importantes, como usuario (no he dejado de buscar el gestor de favoritos perfecto) y como desarrollador, humildemente.
Hola,
(...) sobre todo, cuando uno escribe extensos codigos. y no lo hace muy estructurado que digamos.
y a la hora del host. epa, ¿como que el apache no lo puedo configurar para que no me tire error 404? ¿ensima es php4? ¿y yo que tengo algunas funciones del php5? ¿como que el php no tiene pear? &%$#$% con tu host y toda tu &%$% y #@$% familia...
Pero hay que pensar. Hay que pensar que antes de codificar cualquier cosa (no trivial) uno tiene que tener claro las necesidades y requerimientos de la aplicación que está escribiendo. Evidentemente unas y otros (y lo de más allá) determinará la codificación, entre todo lo demás, el seguir adelante, en definitiva.
La cuestión de la portabilidad tal vez sea un poco distinta. Es decir, si uno tiene una aplicación en producción utilizando PHP 5 (recordemos, porque así lo requerían las necesidades y se estimó oportuno hacerlo así en su momento) y después se ve forzado a cambiar a una versión anterior de PHP...
De todos modos precisamente hablar de proyectos, de diferentes proyectos, implica eso, las necesidades de cada proyecto. Ahí deberíamos atenernos. Es decir, que no creo que tengamos que dilucidar si debemos dejar de usar un tipo de URLs (sea como sea) o comenzar a utilizar otras (sea como sea).
De hecho tal vez dilucidar eso no sea posible porque no estemos hablando de un estándar que hubiera de seguirse ni nada parecido. Estamos hablando de proyectos, de necesidades, de posibilidades de elección de un tipo u otro de URLs, o, a lo menos, de tener presente esto último como algo que puede aportar a nuestra aplicación algún tipo de valor.
roman
06-05-2006, 19:31:55
Yo me vengo fijando en las URLs de los sitios Web desde hace años, incluso antes de saber qué cosa eran las URLs las intuía importantes, como usuario (no he dejado de buscar el gestor de favoritos perfecto) y como desarrollador, humildemente.
Dame una razón, como usuario, de porqué te importa el formato de la url.
Yo entro a un lugar como éste, el club. Veo barras de menús, listas, pestañas, todo muy bien organizadito, y comienzo a dar clicks en este enlace, y luego en este otro. Siempre hay un enlace dispuesto a llevarme a donde yo quiero. Y todo esto puedo hacerlo sin fijarme en la barra de direcciones.
Que tu naturaleza curiosa, como la de la mayoría seguramente de quienes entramos a estos foros de programación, te lleve a interesarte por el formato de las url, es perfectamente entendible. Pero, repito, como usuario, creo que es indiferente. Quizá sería ineresante hacer una encuesta entre usuarios no programadores.
// Saludos
Hola,
Dame una razón, como usuario, de porqué te importa el formato de la url.
Prefiero la URL:
http://mihabana.com
... a la URL:
http://cosasquedejeenlahabana.com
También prefiero la URL:
http://del.icio.us/tutorial+delphi
... a la URL:
http://del.icio.us/index.php?q=tutorial%20delphi
mamcx
06-05-2006, 20:49:59
Date una mirada a http://www.rubyonrails.org/, en especial el videotutorial.
Porque lo de que mapea naturalmente a un desarrollo MVC (model, view, controller)?
Por esto. Imaginate la pagina de inicio. Se hacen tres cosas: Un modelo (que sacaria por ejemplo un mensaje hola mundo), un controlador (llamado INICIO) y una vista (una pagina inicio.html)
Presta atencio a la parte del CONTROLADOR. Si lo llamas "Roman" AUTOMATICAMENTE te cojeria:
www.elsitio.com/Roman
Entonces, es como autowiring: El modelo de los objetos se representa perfectamente en la aplicacion... que de hecho, es el objetivo de tener mayor disciplina en un desarrollo: Separa GUI + Logica + Contenido.
Y resulta que en los nuevos frameworks que son un stack integrado para apliaciones web MVC (que normalmente incorporan generacion de html basado en estandares, ajax, persistencia de objetos, enrutamiento de URL y mas) como RubyOnRails (ruby) TurboGears (python) y Castle (.NET) simplemente se logra una mayor productividad de desarrollo porque el flujo de trabajo es muy predecible y todo se auto-organiza.
Por otro lado, es cierto que a muchos usuarios lo de las Urls les tenga sin cuidado. Pero si miras los documentos de la w3c (reaulta que lo de las URls tambien esta estandarizado) veras que de todas maneras la gente empieza a notar (al menos algunos) que los sitios tienen una estructura.
Por ejemplo, si veo una url:
Articulos/21/Agosto/2005
me supongo que puedo darle directamente
Articulos/22/Agosto/2005
Obviamente se puede con la tipica
?Esto=1&Aquello=2
Pero a partir de cierto punto (# de parametros y su complejidad de interpretacion) ya queda dificil.
Por ultimo, fijate en el disco duro: Son Urls "limpias". A muchos no les interesa como es la estructuras de archivos pero otros si. Siendo todo igual, lo mas sencillo es mejor ;)
Hay mas argumentos, como por ejemplo, de seguridad (es menos obvio la tecnologia y menos obvia que se puede hacer un ataque basado en urls) los de marketing y buscadores (lo mas fuerte) la abastraccion, desde el punto de vista del desarrollador, de la estructura interna.
Esto es algo que estoy trabajando el el CMS que desarrollo. Lo pienso enfocar al mercado latino. Pero resulta que a muchas empresas latinas les interesa manejar contenido en ingles. Asi que :
Version1 del sitio:
Productos/Computadores/Dell2053
Se puede tornar en
Products/Computers/Dell2053
o
Version 2:
(español colombia)
esCo/Productos/Computadores/Dell2053
a
(español mexico)
esMx/Computadores/Dell2053
Pero luego si el sitio se engrandece, se puede reorganizar:
Version 3:
/Colombia/Computadores/Dell2053
/Mexico/Computadores/Dell2053
/Usa/Products/Computers/Dell2053
Y sin embargo:
- Los urls "antiguos" se pueden dejar funcionando. En la version3 del sitio, no existe razon en hacer que
Products/Computers/Dell2053
Usa/Products/Computers/Dell2053
enUS/Products/Computers/Dell2053
Dejen de funcionar. Eso signifa que :
1- Los bookmarks que hagan los usuarios persisten durante mas tiempo
2- Los buscadores ven un sitio mas estable y terminan teniendo mas contenido que indexar, lo que aumenta la importancia
3- El sitio puede crecer de forma organica, e internamente sigue siendo:
Products.aspx?Idioma=esCo&Seccion=Computadores&Ref=Dell2053
Ahora un sub-beneficio: Auto-navegacion!
Si nos ponemos listos, nos podemos olvidar de los amarres de los archivos, directorios y subdirectorios. Y siendo algo listos, podemos autogenera todo el sistema de navegacion.
4- Se `pueden generar Urls mas simples que sea mas practicas en ambientes de navegacion mas restringido:
Los numeros de caracteres se pueden reducir o para los usuarios que son invidentes (piensen en que hay mucha gente que no puede ver o necesita asistencia en la navegacion, por ejemplo, mi tia usa un software para ello!) una navegacion:
Productos/Computadores/Dell1
a la hora de escribir en un CELULAR o una PDA o de escuchar mediante un lector de voz, es mas claro que el sistema de parametros.
Evidentemente, la ventaja de las urls estaticas aumentan en la medida que aumenta el tamaño y complejidad del sitio y disminuyen a medidad que el sitio sea mas una aplicacion web mas que uno para usuarios. Y sin enrutamiento, no tiene nigun chiste.
Por ultimo, hacer urls asi no es TAN dificil. Como mencionaron, se puede usar las propiedades de apache o un modulo http en .NET o lo que sea.
Un poco mas de info:
http://www.port80software.com/support/articles/nextgenerationurls
Y no olviden que no estan obligados a hacer esto. Ni tampoco implica cambiar los sitios actuales sin razon.
Emilio
06-05-2006, 22:20:36
Bueno por fin, mamcx nos da algunas razones con cierto sentido común, gestión de paises, invidentes, orden en un sitio grande etc...
Ahora bien, la siguiente url http://www.clubdelphi.com/foros/archive/index.php/f-11-p-18.html
limpia, como vosotros la llamáis, incluso con terminación .html de lo cual hasta el momento no habíamos hablado, no es más que una limpia/sucia trampa cara a los buscadores, eso mismo se puede hacer con con tan sólo una línea de código, sin necesidad de modificar directivas de Apache ni .htaccess ni nada.
¿qué logramos con ello? pues tener todas la direcciones limpias como le llamáis, totalmente inútiles para el usuario ¿quién escribe una url?, por otro lado los buscadores se encuentran a sus anchas, todo perfectamente enlazado y organizado, y por si ello fuese poco, visible desde una PDA y totalmente legible por un invidente.
Además, para cada documento tendremos dos entradas en los buscadores :D
Hola,
Muy interesante artículo (http://www.port80software.com/support/articles/nextgenerationurls) el que has enlazado Mario. Y los que refiere el autor del mismo tampoco parecen tener desperdicio:
Articles
Numerous articles have been written about the need for clean URLs. A few of the more prominent ones are cited here.
Tim Berners Lee's Cool URIs don't change (http://www.w3.org/Provider/Style/URI)
Jakob Nielsen on URL as UI (http://www.useit.com/alertbox/990321.html)
Bill Humphries @ Zeldman's on URLs! URLs! URLs! (http://www.alistapart.com/articles/urls/)
Clean Up Those URLs with Apache (http://www.ddj.com/documents/s=2747/nam1012432182/index.html)
Making "clean" URLs with Apache and PHP (http://www.evolt.org/article/Making_clean_URLs_with_Apache_and_PHP/18/22880/)
Search Engine Friendly URLs with PHP and Apache: Part I (http://www.evolt.org/article/Search_Engine_Friendly_URLs_with_PHP_and_Apache/17/15049/) and Part II (http://evolt.org/article/Search_Engine_Friendly_URLs_Part_II/17/17171)
roman
07-05-2006, 02:52:50
Muchas gracias por la respuesta Mario. Debe ser que ando muy espeso estos días pero me cuesta trabajo ver, no ya la conveniencia entre un tipo de urls u otro, sino que creo que realmente no estoy entendiendo a que se refieren con urls limpias. Vamos a ver, si yo tengo un sitio muy grande con mucho contenido, ciertamente voy a organizarlo en directorios y subdirectorios. De hecho pensé que eso estaba claro desde un principio. Ya sea
Articulos/21/Agosto/2005
ó
Mexico/Computadores/Dell2053
en cualquier caso es lo que yo haría, independientemente de url limpias o sucias.
Otra cosa sin embargo es cuando estamos hablando de, por ejemplo
/buscar/lenguaje/delphi
en lugar de
buscar.php?lenguaje=delphi
Aquí es donde yo pregunto, ¿para qué quiero una url como la primera? ¿Por qué en ese caso quiero dar la impresión de una estructura de directorios?
De cualquier forma, voy a revisar el enlace que pones y releer todo este hilo a ver qué saco en claro.
Ahora, en cuanto a lo de MVC, la verdad sigo sin entender. Estoy de acuerdo en separar la interfaz, la lógica y el contenido pero sigo sin ver qué tiene que ver tal separación con la forma de las urls. Tengo pendiente ver lo de Ruby, lo haré el lunes que disponga de una conexión rápida.
// Saludos
Otra cosa sin embargo es cuando estamos hablando de, por ejemplo /buscar/lenguaje/delphi en lugar de buscar.php?lenguaje=delphi Aquí es donde yo pregunto, ¿para qué quiero una url como la primera? ¿Por qué en ese caso quiero dar la impresión de una estructura de directorios? La respuesta es sencilla intentar usar urls limpias no significa usar a rajatabla la regla de las barras de directorio para todo, especialmente en las busquedas avanzadas o complejas. Asi que cuando hay varios parametros posibles y estos pueden variar, no se usan urls completamente limpias. Eso si, yo usaria: buscar?lenguaje=delphi Es preferible ocultar el .php de cara al usuario y los buscadores de modo que las urls sean neutras con respecto a la tecnologia o lenguaje de programacion que use internamente la web (facilitando el cambio, si fuese necesario, de la web a cualquier otra tecnologia o lenguaje). Saludos
Perberos
08-05-2006, 09:07:54
Creo haber leido por ahi arriba. Que hay que ver la perspectiva de los usuarios.
Y me parecio interesante compartir este articulo, que no tiene mucho que ver con lo de las urls limpias. Si no, criticas de como se diseña una web.
Vicent Flanders's Web Pages That Suck
http://www.webpagesthatsuck.com/
Es un libro, pero creo que hay pequeño parrafos para leer dentro de la web.
Es muy interesante para los diseñadores, porque contiene cosas que uno ignora a veces.
Bueno, ahora que estoy en las ramas. (porque me fui por las ramas)
En mi web, puse un frame, para evitar que el usuario vea los parametros.
Aunque yo creo, que teniendo un buen sistema de navegacion. el usuario no le interesara utilizar la barra de direcciones.
Ademas, el usuario no es adivino. sin un mapa el usuario no sabe donde esta, ni hacia donde va. Y menos va a conocer todos los parametros que se pueden ingresar en un .php
ademas, con los: if($_SERVER[HTTP_REFERED] == '')
{
header('Location: www.google.com');
}
uno puede repeler a los curiosos. o utilizando algunos metodos para despistar al usuario para que no se meta en los comandos que genera el propio php. (si esa es la finalidad claro)
die("saludos"); <---- parecido al de roman jejeje
vBulletin v3.6.8, Derechos ©2000-2024, Jelsoft Enterprises Ltd.