Hola amigos,
Llevo unos días empoyando todo el tema de REST, que por cierto me está
encantando.
Pero me ronda la cabeza una duda existencial:
Cuando accedemos al método (acción) “destroy”, y nos monta todo el
rollo javascript de onClick…
¿No es esto javascript intrusivo? Es decir, que creo yo que si tienes
desactivado el javascript en el navegador no vaa a funcionar.
Aunque entiendo que a esta acción sólo vas a acceder desde una vista
de administración y por tanto es menos problema, ya que puedes
especificarlo cómo requerimiento necesario para acceder a ese panel de
administración.
Pero al margen de lo que yo pienso, me gustaría saber que pensáis
vostros de este tema.
Si pensáis que es una chorrada, no me hagáis ni caso. Pero llevo unos
días dandole vueltas…
Un saludo a todos.
–
Fernando V.
Web Designer
http://www.fernandoval.com
2009/4/16 Fernando [email protected]
Cuando accedemos al método (acción) “destroy”, y nos monta todo el
rollo javascript de onClick…
¿No es esto javascript intrusivo?
Si. Totalmente intrusivo.
Es decir, que creo yo que si tienes
desactivado el javascript en el navegador no vaa a funcionar.
De ahÃ, el que cuando estás desarrollando una aplicación, primero la
diseñas
sin javascripts, y cuando esté hecha, la mejoras con js.
Esta técnica tiene nombre y todo, lo que la hace mucho más importante,
creo
que era algo asà como javascript progressive enchantment, pero por el
número
de resultados de google, creo que no es asÃ. Seguro que algún intelecto
de
la lista es capaz de desvelar el nombre buscado.
Mira! es una cuestión que tenÃa ganas que saliera en la lista
Primero una sugerencia para el ASUNTO del hilo:
REST no es javascript
En todo caso es la forma en la que implementa RAILS el uso de los verbos
HTTP lo que genera javascript INTRUSIVO.
Lo que me interesa a mi es saber si alguien me puede confirmar si RAILS
genera por defecto javascript intrusivo en todos los lados con los
HELPERS
que nos facilita.
El 16 de abril de 2009 15:19, Fernando [email protected] escribió:
2009/4/16 Guillermo [email protected]
Bueno, ante todo hay que diferenciar entre REST el estilo arquitectural
y
las implementaciones. En todo caso, serán intrusivas ciertas cosas de la
implementación Rails del estilo REST
que era algo asà como javascript progressive enchantment, pero por el número
de resultados de google, creo que no es asÃ. Seguro que algún intelecto de
la lista es capaz de desvelar el nombre buscado.
Progressive *enhancement, que es un término que si no me equivoco
inventó
Dan Champion hace ya años.
*
De todas formas, Progressive Enchantment me ha encantado como nombre de
Startup 
Te lo robo
Pero Guillermo, entonces si diseñas una aplicación primero sin
javascript, significa a su vez primero sin REST, ¿no?
Y si no me equivo, Rails a día de hoy viene con el REST por defecto,
con lo cual empezar sín REST requiere trabajo adicional…
Quizas entonces hay que pensar en términos de (zona pública=>REST y el
Javascript nos afecta / zona admin=>REST y asumimos un mínimo de
javascript). Y luego progresivamente vamos enriqueciendo la zona
pública.
El día 16 de abril de 2009 15:41, Guillermo [email protected]
escribió:>>
–
Guillermo Álvarez
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–
Fernando V.
Web Designer
http://www.fernandoval.com
A ver, vamos por partes, si no me equivoco, esto parte de generar
scaffold
que tira los codigos automaticamente para las vistas, que es ahi donde
se da
el javascript intrusivo.
El mismo evento de onclick se puede armar por un observer (si no me
equivoco
con eso ya dejaria de ser intrusivo) y solucionar esa parte, y esto
puede
hacerse modificando el generador del scaffold.
En realidad el problema radica en intentar ahorrar laburo por un
generador
sin mirarlo a lujo de detalle.
Agustin Viñao
www.agustinvinao.com
skype: agustinvinao
2009/4/16 Fernando [email protected]
No, no Andrés que no digo yo que REST sea javascript, lo que digo es
que lleva implicita una pequeña ración de javascript en algunos
helpers…
Ok. Entonces decimos lo mismo 
El 16 de abril de 2009 15:50, Fernando [email protected] escribió:
No, no Andrés que no digo yo que REST sea javascript, lo que digo es
que lleva implicita una pequeña ración de javascript en algunos
helpers…
El día 16 de abril de 2009 15:48, Fernando [email protected]
escribió:> El día 16 de abril de 2009 15:41, Guillermo [email protected] escribió:
Es decir, que creo yo que si tienes
Guillermo Álvarez
–
Fernando V.
Web Designer
http://www.fernandoval.com
–
Fernando V.
Web Designer
http://www.fernandoval.com
Agustin, si no me equivoco, son algunos helpers los “culpables” y no
el scaffold.
Lo de montarlo con un observer, a mi ahora se me queda grande para mis
conocimientos, pero me lo apunto para más adelante
cómo “solucióntotal”. Lo digo en serio eh, que me lo estoy apuntando…
El día 16 de abril de 2009 15:51, Agustin Nicolas Viñao Laseras
[email protected]
escribió:> _____________
Cuando accedemos al método (acción) “destroy”, y nos monta todo el
diseñas
sin javascripts, y cuando esté hecha, la mejoras con js.
Guillermo Álvarez
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–
Fernando V.
Web Designer
http://www.fernandoval.com
Ah pues si, yo también me apunto…
El día 16 de abril de 2009 15:59, Fernando [email protected]
escribió:>> con eso ya dejaria de ser intrusivo) y solucionar esa parte, y esto puede
2009/4/16 Fernando [email protected]
número
[email protected]
–
Fernando V.
Web Designer
http://www.fernandoval.com
–
Fernando V.
Web Designer
http://www.fernandoval.com
En realidad el problema radica en intentar ahorrar laburo por un generador
sin mirarlo a lujo de detalle.
Estoy deacuerdo contigo ¿Has hecho el cambio que dices para modificar el
scaffold?
Si la respuesta es SI ¿puedes explicar el código que has cambiado?
Un saludo
El 16 de abril de 2009 15:51, Agustin Nicolas Viñao Laseras <
[email protected]> escribió:
Andres me refiero a que por medio del scaffold se genera las vista con
esta
porcion de codigo, seria cuestion de revisar los pasos que hace el
scaffold
y ver donde esta esta parte, sea en un helper o donde este.
Al principio usaba mas el scaffold, a medida que uno va ganando
experiencia
desde mi punto de vistal el scaffold lo usa solo para cosas que no
llegan al
vistante del sitio, como mucho a los admins, pero siempre es mejor tener
el
mayor control del codigo y no tanto codigos generados automaticamente.
Mismo hay que decir, que RoR tiene una fuerte participacion de
Javascript,
buscando utilizar tecnicas no intrusivas, igual debemos resaltar que la
tendencia de tener javascript no instrusivo tiene como finalidad buscar
que
para navegantes sin JS activo puedan tener la misma funcionalidad:
*Asegure que las paginas sigan siendo utilizables cuando se desconectan
o no
se soporten los scripts, applets u otros objetos de programación. Si
esto no
es posible, proporcione información equivalente en una pagina
alternativa
accesible [Prioridad 1]
*
Ahora la pregunta es ¿que tantas cosas se pueden plantear sin JS?
Si comparto tener JS no intrusivo para ordenar la programacion, pero
pensar
en resolver este tema para que se puedan hacer las mismas cosas sin JS
es,
desde mi punto de vista, poco util.
Agustin Viñao
www.agustinvinao.com
agustinvinao (Skype)
2009/4/16 Andrés gutiérrez [email protected]
Para los vagos que no quieran perder el tiempo buscando “javascript
enhancement” en google. Yo lo recordaba de haberlo leÃdo en A List
Apart.
2009/4/16 Manuel González Noriega [email protected]:
De ahÃ, el que cuando estás desarrollando una aplicación, primero la
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–
Carlos MatallÃn
[email protected]
http://c.matallin.com
+34 607377647
por supuesto, llegado el momento, disponiendo de tiempo, es algo que me
gustaria cambiar, es como todos los patch que se van subien a rails, si
uno
hace un cambio de esos, y al subirlo como un patch deciden que es util
para
todos, lo cambian en rails directamente con la informacion que uno les
brindo.
Te paso un screencast de Ryan, el cual explica como hacer un patch y
subirlo
a rails
No solo se suben correcciones sino tambien aportes.
sl2
Agustin Viñao
www.agustinvinao.com
agustinvinao (Skype)
2009/4/16 Andrés gutiérrez [email protected]
Yo Agustin, aún estoy en la fase en que el scaffold me ayuda mucho
cómo punto de partida…
Y comparto contigo, que tampoco hay que ser “taliban” en esto del
javascript no intrusivo, y utilizar el sentido común para ver donde
puede dar más problemas y donde no pasa nada por utilizarlo.
¿Acaso es una gran pérdida de tiempo, la cantidad ingente de
frameworks, recursos, aplicaciones, información, formación, etc
entorno a javascript? Yo personalmente no lo creo.
El día 16 de abril de 2009 16:12, Agustin Nicolas Viñao Laseras
[email protected]
escribió:> buscando utilizar tecnicas no intrusivas, igual debemos resaltar que la
Si comparto tener JS no intrusivo para ordenar la programacion, pero pensar
generador sin mirarlo a lujo de detalle.
scaffold que tira los codigos automaticamente para las vistas, que es ahi
skype: agustinvinao
Javascript nos afecta / zona admin=>REST y asumimos un mínimo de
¿No es esto javascript intrusivo?
Esta técnica tiene nombre y todo, lo que la hace mucho más importante,
Web Designer
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
2009/4/16 Carlos MatallÃn [email protected]
Understanding Progressive Enhancement – A List Apart
Progressive Enhancement with JavaScript – A List Apart
–
Carlos MatallÃn
Esos eran los que querÃa buscar.
–
Guillermo Ãlvarez
Sent from Madrid, Comunidad de Madrid
Hola Fernando, hace poco escribà un articulo relacionado al tema en mi
humilde blog:
http://rubenonrails.com/2009/03/13/javascript-no-intrusivo-con-jquery-en-rails
Saludos.
2009/4/16 Fernando [email protected]
Pero Guillermo, entonces si diseñas una aplicación primero sin
javascript, significa a su vez primero sin REST, ¿no?
Creo que estás confundiendo REST con Javascript no intrusivo… y poco
tienen que ver por no decir nada.
Rest: Transferencia de Estado Representacional - Wikipedia, la enciclopedia libre
Es una forma de organizar los recursos e interacción con ellos, es más,
ni
siquiera se necesita un navegador para acceder a esos recursos. Con que
sepas la dirección del recurso, ya sabrás listar, mostrar, editar,
borrar y
crear incluso desde consola.
A esos recuersos puedes acceder mediante forumularios e hipervÃnculos
asÃ
como con Javascript.
Creo que se debe de usar resources (REST) (como los entiende rails)
siempre
(habiendo excepciones claro).
2009/4/16 Manuel González Noriega [email protected]
De todas formas, Progressive Enchantment me ha encantado como nombre de
Startup Te lo robo
Bueno… un error lo tiene cualquiera. Pero aunque se refiera a otra
cosa
Enchantment no estarÃa tan mal:
Enchantment may refer to:
[image: Sister
project]http://en.wiktionary.org/wiki/Special:Search/EnchantmentLook
up enchantment http://en.wiktionary.org/wiki/enchantment in
Wiktionary http://en.wikipedia.org/wiki/Wiktionary, the free
dictionary.
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.
Saludos.
El 16/04/09, Guillermo [email protected] escribió:
Si comparto tener JS no intrusivo para ordenar la programacion, pero
pensar en resolver este tema para que se puedan hacer las mismas cosas
sin
JS >>es, desde mi punto de vista, poco util.
Si me tengo que poner a cambiar RAILS para ello, para también, ademas se
me
escapa de mis conocimientos. Pero si me lo diera un ada con una barita
mágica, yo lo cogerÃa ¿tú no?
El 16 de abril de 2009 16:12, Agustin Nicolas Viñao Laseras <
[email protected]> escribió: