¿REST es Javascript "intrusivo"?

Community ES
21

No, que va no lo confundo para nada, puesto que llevo tiempo
trabajando con javascript y unos días empollando el tema REST.
Además en algún post anterior ya lo he comentado… pero gracias de
todos modos Guilermo :wink:

El día 16 de abril de 2009 16:49, Guillermo [email protected]
escribió:> sepas la dirección del recurso, ya sabrás listar, mostrar, editar, borrar y

Bueno… un error lo tiene cualquiera. Pero aunque se refiera a otra cosa

–
Guillermo Álvarez
Sent from Madrid, Comunidad de Madrid

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Fernando V.
Web Designer
http://www.fernandoval.com

22

2009/4/16 Ruben. D. [email protected]:

Un buen tip importante que vi husmeando en el codigo de spot.us1 es
que puedes crear una “named route” apuntando a la acción destroy de un
recurso:

map.logout ‘/logout’, :controller => ‘sessions’, :action => ‘destroy’

y con eso el helper link_to ya no necesitaria generar el codigo
javascript para apuntar a esa acción.

Sólo añadir que este truco está bien si no te importa que alguien
active ese destroy por error: en la mayoría de los casos los destroy
deben ir vía POST para no ser activados por robots, crawlers, etc.

23

Ostia!!

Sólo añadir que este truco está bien si no te importa que alguien
active ese destroy por error: en la mayoría de los casos los destroy
deben ir vía POST para no ser activados por robots, crawlers, etc.

Estaba pensando que el truquito de Ruben molaba, pero esto no mola nada.

El 16 de abril de 2009 17:04, Raul M. [email protected]
escribió:

24

Le ehcaré un ojo Rubén, tiene buena pinta el tema… :slight_smile:

2009/4/16 Ruben. D. [email protected]:

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Fernando V.
Web Designer
http://www.fernandoval.com

25

2009/4/16 Raul M. [email protected]

Sólo añadir que este truco está bien si no te importa que alguien
active ese destroy por error: en la mayoría de los casos los destroy
deben ir vía POST para no ser activados por robots, crawlers, etc.

Y si la suerte sonríe, llegamos al famoso GoogleWebAcceleratorGate de
2005
:smiley:

Recordemos que GET (entre otros) debe ser idempotente, es decir, su
acción
repetida debe tener los mismo efectos. Por esto queda descartado un GET
que
destruya el recurso, ya que obviamente los efectos de hacerlo por
segunda y
sucesivas veces serían distintos de la primera. Basicamente, 410 Gone.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

26

Sólo por aportar mi granito de arena a este asunto…

como bien dicen, los GET tendrian que ser “safe” y no cambiar el
estado de nuestras bases de datos, por ello, Ryan B. realizó un
buen screencast sobre como “sortearlo”.

Esto puede estar bien para 2 o 3 modelos, porque como tengas 40
distintos, el trabajo extra se me antoja excesivo:

Como resumen, utiliza javascript no intrusivo para borrar registros o
bien envia al usuario por get a una pagina donde se le pida
confirmación para el borrado y que sea un simple formulario.

Mucho cuuuuurrroooo!

Saludos,

Isaac Feliu

27

2009/4/16 Ruben. D. [email protected]:

Respecto a lo que indica Manuel tiene mucha razón, hasta ahora me vengo
preguntando hasta que nivel es bueno usar los helpers de Rails para Ajax si
todos generan Javascript intrusivo, quisiera leer buenas posiciones al
respecto ya que he visto personas que lo usan sin mucha preocupación. Sera
que a estas alturas pensar en hacer una aplicación completamente con
Javascript no intrusivo es una locura y perdida de tiempo no muy bien
justificada?. He visto casos en los que la solución sin Javascript es casi
inviable o demasiada compleja, por ejemplo en el clásico caso de los
elementos select anidados.

Por supuesto todo depende del proyecto, yo en lo posible defiendo el
enfoque de la mejora progresiva[1]: una primera capa de HTML plano que
permita llevar a cabo la funcionalidad que queremos (aunque el
interfaz no luzca como queramos) y que el propio JS se encargue de
reemplazar o mejorar la versión accesible (en este caso reemplazando
los formularios y botones de eliminar por enlaces que disparan
acciones ajax, etc).

Obviamente el coste de desarrollo es mayor que si hacemos sólo una
versión con JS, pero el camino inverso (lo que llaman “graceful
degradation”, hacer una versión accesible a posteriori) suele ser un
camino mucho más difícil y costoso.

[1]

28

Los generadores de scaffold REST (por defecto ahora en Rails) generan el
enlace para hacer el destroy con un trocito de javascript para montar un
formulario “hidden” y poder hacer así una petición delete. Con lo que la
cosa no va si tienes javascript desactivado (se hará un show en el mejor
de los casos).

En su momento me encontré con el problema e hice la siguiente búsqueda
en google:
http://www.google.es/search?q=rails+rest+without+javascript

Tuve suerte y fui al screencast de Ryan (primer resultado). Ahí te
cuenta cómo lidiar con el tema con varias posibilidades.

Espero que a vosotros también os ayude.

Saludos!

29

Hola Andres, que raro que no te funcione, yo lo he usado para el logout
de
una aplicación y si me ha andado.

Respecto a lo que indica Manuel tiene mucha razón, hasta ahora me vengo
preguntando hasta que nivel es bueno usar los helpers de Rails para Ajax
si
todos generan Javascript intrusivo, quisiera leer buenas posiciones al
respecto ya que he visto personas que lo usan sin mucha preocupación.
Sera
que a estas alturas pensar en hacer una aplicación completamente con
Javascript no intrusivo es una locura y perdida de tiempo no muy bien
justificada?. He visto casos en los que la solución sin Javascript es
casi
inviable o demasiada compleja, por ejemplo en el clásico caso de los
elementos select anidados.

Ojalá llueva algo!

30

Hola Fernando

Hace tiempo leí este articulo [1] sobre este tema de que rails no
funcione,
en principio, con javascript desactivado. El articulo me gusto mucho
explica
a la perfección tu duda y es de fácil comprension.

Espero te ayude

Jorge G.
Desarrollador Rails Freelance

1
http://ruido-blanco.net/blog/archivos/2007/03/15/rails-¡mira-mama-¡sin-javascript/

El 16 de abril de 2009 15:19, Fernando [email protected] escribió:

31

Le echaremos un ojo, tiene buena pinta…

El día 17 de abril de 2009 9:18, Jesús García Carrero
[email protected]
escribió:> Tuve suerte y fui al screencast de Ryan (primer resultado). Ahí te

cuenta cómo lidiar con el tema con varias posibilidades.

Espero que a vosotros también os ayude.

Saludos!

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Fernando V.
Web Designer
http://www.fernandoval.com

32

Un enlace más para la lista

tiene algún caso práctico y aunque lo explican con PHP como ejemplo
creo que puede captarse la idea fácilmente.

Espero no saturar con los links!

2009/4/17 Fernando [email protected]:

Espero te ayude

especificarlo cómo requerimiento necesario para acceder a ese panel de

Web Designer
http://www.fernandoval.com

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Carlos Matallín
[email protected]
http://c.matallin.com
+34 607377647

33

Se me acumulan… jejeje
Muchas gracias.

El día 17 de abril de 2009 12:02, Jorge G. [email protected]
escribió:>

rollo javascript de onClick…
días dandole vueltas…
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es

–
Fernando V.
Web Designer
http://www.fernandoval.com