Forum: Rails-ES ¿REST es Javascript "intrusivo"?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Fernando (Guest)
on 2009-04-16 17:25
(Received via mailing list)
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
Guillermo (Guest)
on 2009-04-16 17:42
(Received via mailing list)
2009/4/16 Fernando <removed_email_address@domain.invalid>

> 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.
Andrés G. (Guest)
on 2009-04-16 17:43
(Received via mailing list)
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 <removed_email_address@domain.invalid> 
escribió:
Manuel González Noriega (Guest)
on 2009-04-16 17:47
(Received via mailing list)
2009/4/16 Guillermo <removed_email_address@domain.invalid>

>
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
Fernando (Guest)
on 2009-04-16 17:48
(Received via mailing list)
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 
<removed_email_address@domain.invalid>
escribió:>>
> --
> Guillermo Álvarez
>
>
> _______________________________________________
> Ror-es mailing list
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Fernando (Guest)
on 2009-04-16 17:50
(Received via mailing list)
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 
<removed_email_address@domain.invalid>
escribió:> El día 16 de abril de 2009 15:41, Guillermo 
<removed_email_address@domain.invalid> 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 V. (Guest)
on 2009-04-16 17:52
(Received via mailing list)
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 <removed_email_address@domain.invalid>
Andrés G. (Guest)
on 2009-04-16 17:52
(Received via mailing list)
>>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 <removed_email_address@domain.invalid> 
escribió:
Andrés G. (Guest)
on 2009-04-16 17:58
(Received via mailing list)
>>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 <
removed_email_address@domain.invalid> escribió:
Fernando (Guest)
on 2009-04-16 18:00
(Received via mailing list)
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
<removed_email_address@domain.invalid>
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
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Fernando (Guest)
on 2009-04-16 18:00
(Received via mailing list)
Ah pues si, yo también me apunto...

El día 16 de abril de 2009 15:59, Fernando 
<removed_email_address@domain.invalid>
escribió:>> con eso ya dejaria de ser intrusivo) y solucionar esa parte, y esto 
puede
>> 2009/4/16 Fernando <removed_email_address@domain.invalid>
>>>
>>> >
>>> > número
>>> > removed_email_address@domain.invalid
>>> _______________________________________________
>>
>
>
>
> --
> Fernando V.
> Web Designer
> http://www.fernandoval.com
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Agustin V. (Guest)
on 2009-04-16 18:13
(Received via mailing list)
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 <removed_email_address@domain.invalid>
Andrés G. (Guest)
on 2009-04-16 18:18
(Received via mailing list)
>>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 <
removed_email_address@domain.invalid> escribió:
Carlos Matallín (Guest)
on 2009-04-16 18:20
(Received via mailing list)
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.

http://www.alistapart.com/articles/understandingpr...
http://www.alistapart.com/articles/progressiveenha...

2009/4/16 Manuel González Noriega <removed_email_address@domain.invalid>:
>
>> De ahí, el que cuando estás desarrollando una aplicación, primero la
>
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Carlos Matallín
removed_email_address@domain.invalid
http://c.matallin.com
+34 607377647
Agustin V. (Guest)
on 2009-04-16 18:22
(Received via mailing list)
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

http://railscasts.com/episodes/50-contributing-to-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 <removed_email_address@domain.invalid>
Fernando (Guest)
on 2009-04-16 18:22
(Received via mailing list)
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
<removed_email_address@domain.invalid>
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
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Guillermo (Guest)
on 2009-04-16 18:33
(Received via mailing list)
2009/4/16 Carlos Matallín <removed_email_address@domain.invalid>
>
> http://www.alistapart.com/articles/understandingpr...
> http://www.alistapart.com/articles/progressiveenha...
>
> --
> Carlos Matallín


Esos eran los que quería buscar.

--
Guillermo Álvarez

Sent from Madrid, Comunidad de Madrid
Ruben D. (Guest)
on 2009-04-16 18:49
(Received via mailing list)
Hola Fernando, hace poco escribí un articulo relacionado al tema en mi
humilde blog:

http://rubenonrails.com/2009/03/13/javascript-no-i...

Saludos.
Guillermo (Guest)
on 2009-04-16 18:49
(Received via mailing list)
2009/4/16 Fernando <removed_email_address@domain.invalid>

> 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: http://es.wikipedia.org/wiki/Representational_State_Transfer

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 <removed_email_address@domain.invalid>

> 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/Encha...
up *enchantment <http://en.wiktionary.org/wiki/enchantment>* in
Wiktionary <http://en.wikipedia.org/wiki/Wiktionary>, the free
dictionary.

   - Incantation <http://en.wikipedia.org/wiki/Incantation> or
enchantment,
   a magical spell, charm or bewitchment, in traditional fairy tales or
fantasy
Ruben D. (Guest)
on 2009-04-16 18:54
(Received via mailing list)
Un buen tip importante que vi husmeando en el codigo de spot.us[1] 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.

[1]: http://github.com/spot-us/spot-us/tree/master

Saludos.

El 16/04/09, Guillermo <removed_email_address@domain.invalid> escribió:
Fernando (Guest)
on 2009-04-16 18:56
(Received via mailing list)
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 ;-)

El día 16 de abril de 2009 16:49, Guillermo 
<removed_email_address@domain.invalid>
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
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Fernando (Guest)
on 2009-04-16 18:59
(Received via mailing list)
Le ehcaré un ojo Rubén, tiene buena pinta el tema... :-)



2009/4/16 Ruben. D. <removed_email_address@domain.invalid>:
> _______________________________________________
> Ror-es mailing list
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Raul M. (Guest)
on 2009-04-16 19:05
(Received via mailing list)
2009/4/16 Ruben. D. <removed_email_address@domain.invalid>:
> Un buen tip importante que vi husmeando en el codigo de spot.us[1] 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.
>
> [1]: http://github.com/spot-us/spot-us/tree/master

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.
Andrés G. (Guest)
on 2009-04-16 19:21
(Received via mailing list)
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. <removed_email_address@domain.invalid>
escribió:
Manuel González Noriega (Guest)
on 2009-04-16 19:50
(Received via mailing list)
2009/4/16 Raul M. <removed_email_address@domain.invalid>

> > [1]: http://github.com/spot-us/spot-us/tree/master
>
> 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
:D

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
Isaac Feliu Pérez (Guest)
on 2009-04-16 19:55
(Received via mailing list)
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:

http://railscasts.com/episodes/77-destroy-without-javascript

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
Ruben D. (Guest)
on 2009-04-16 20:12
(Received via mailing list)
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!
Raul M. (Guest)
on 2009-04-16 20:42
(Received via mailing list)
2009/4/16 Ruben. D. <removed_email_address@domain.invalid>:
> 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]
http://www.alistapart.com/articles/understandingpr...
Jesús García Carrero (Guest)
on 2009-04-17 11:19
(Received via mailing list)
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!
Fernando (Guest)
on 2009-04-17 12:58
(Received via mailing list)
Le echaremos un ojo, tiene buena pinta...

El día 17 de abril de 2009 9:18, Jesús García Carrero
<removed_email_address@domain.invalid>
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
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Jorge G. (Guest)
on 2009-04-17 14:02
(Received via mailing list)
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/r...

El 16 de abril de 2009 15:19, Fernando <removed_email_address@domain.invalid> 
escribió:
Fernando (Guest)
on 2009-04-17 14:08
(Received via mailing list)
Se me acumulan... jejeje
Muchas gracias.

El día 17 de abril de 2009 12:02, Jorge G. 
<removed_email_address@domain.invalid>
escribió:>
>> rollo javascript de onClick...
>> días dandole vueltas...
>> removed_email_address@domain.invalid
>> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>
> _______________________________________________
> Ror-es mailing list
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>
>



--
Fernando V.
Web Designer
http://www.fernandoval.com
Carlos Matallín (Guest)
on 2009-04-24 13:08
(Received via mailing list)
Un enlace más para la lista
http://www.smashingmagazine.com/2009/04/22/progres...
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 <removed_email_address@domain.invalid>:
>> Espero te ayude
>>>
>>> especificarlo cómo requerimiento necesario para acceder a ese panel de
>>>
>> _______________________________________________
> Web Designer
> http://www.fernandoval.com
> _______________________________________________
> Ror-es mailing list
> removed_email_address@domain.invalid
> http://lists.simplelogica.net/mailman/listinfo/ror-es
>



--
Carlos Matallín
removed_email_address@domain.invalid
http://c.matallin.com
+34 607377647
This topic is locked and can not be replied to.