observe_field sous rails 4
22 views
Skip to first unread message
ziburudebian
Feb 11, 2016, 7:14:23 AM2/11/16
to Railsfrance
bonjour
avant sous rails2 j'utiliser observe_field pour tester ce qui se passer dans une liste deroulante, puis dans le controller je faisais un render update pour mettre à jour la zone de mon formulaire
maintenant sous rails4 cela ne me semble pas possible, il faut que je passe par du javascript ou jquery
pouvez-vous confirmer ?
merci
avant sous rails2 j'utiliser observe_field pour tester ce qui se passer dans une liste deroulante, puis dans le controller je faisais un render update pour mettre à jour la zone de mon formulaire
maintenant sous rails4 cela ne me semble pas possible, il faut que je passe par du javascript ou jquery
pouvez-vous confirmer ?
merci
Florian Dutey
Feb 11, 2016, 11:18:29 PM2/11/16
to rails...@googlegroups.com
Salut,
A partir de rails 3, les choses ont pas mal change. Si tu dois faire une update, tu vas devoir fixer beaucoup de bugs tant lapi a change (et observe field nest plus, le standard etant devenu jquery).
Va falloir que tu geres la logique client toi meme. C pas tres complique ( on("change", ... en jquery).
Ceci dit, et au risque de paraitre meprisant (ce qui n'est pas le but), le developpement web a beaucoup evolue depuis rails 2.
Les ignominies telles que le rjs ont disparu, et, bien que les helpers de vues rails supportent toujours des "options ajax", c'est vivement recommande de ne pas les utiliser (je recommande meme vivement de ne pas utiliser rails pour faire du rendering, a part json). Exit asset pipeline aussi.
De meme, l'idee d'un serveur qui sert un document html qu'on "enrichi" par la suite avec du js et du css est bien morte. Du moins, pour ce qui concerne les applications web.
Ca depend evidemment du type de projet que tu developpes mais pour eviter les problemes sur le long terme, c'est mieux d'avoir un backend qui ne retourne que du data et nessaie pas de manipuler l'etat du client.
Les technos frontend sont maintenant tres matures et essayer de les piloter en ruby (via la pipeline, ou des taches rake) est une tres mauvaise idee aussi.
Donc bye pipeline, bonjour webpack + react / ember.
;)
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse rails...@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "Railsfrance".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.
Cyril Mougel
Feb 12, 2016, 3:30:54 AM2/12/16
to ML Rails France
2016-02-12 5:18 GMT+01:00 Florian Dutey <fdu...@gmail.com>:
> Salut,
>
> A partir de rails 3, les choses ont pas mal change. Si tu dois faire une
> update, tu vas devoir fixer beaucoup de bugs tant lapi a change (et observe
> field nest plus, le standard etant devenu jquery).
> Va falloir que tu geres la logique client toi meme. C pas tres complique (
> on("change", ... en jquery).
>
> Ceci dit, et au risque de paraitre meprisant (ce qui n'est pas le but), le
> developpement web a beaucoup evolue depuis rails 2.
> Les ignominies telles que le rjs ont disparu, et, bien que les helpers de
> vues rails supportent toujours des "options ajax", c'est vivement recommande
> de ne pas les utiliser (je recommande meme vivement de ne pas utiliser rails
> pour faire du rendering, a part json). Exit asset pipeline aussi.
> De meme, l'idee d'un serveur qui sert un document html qu'on "enrichi" par
> la suite avec du js et du css est bien morte. Du moins, pour ce qui concerne
> les applications web.
>
> Ca depend evidemment du type de projet que tu developpes mais pour eviter
> les problemes sur le long terme, c'est mieux d'avoir un backend qui ne
> retourne que du data et nessaie pas de manipuler l'etat du client.
>
> Les technos frontend sont maintenant tres matures et essayer de les piloter
> en ruby (via la pipeline, ou des taches rake) est une tres mauvaise idee
> aussi.
> Donc bye pipeline, bonjour webpack + react / ember.
C'est clairement de l'opinion personnel. Rails est largement utilisé
> Salut,
>
> A partir de rails 3, les choses ont pas mal change. Si tu dois faire une
> update, tu vas devoir fixer beaucoup de bugs tant lapi a change (et observe
> field nest plus, le standard etant devenu jquery).
> Va falloir que tu geres la logique client toi meme. C pas tres complique (
> on("change", ... en jquery).
>
> Ceci dit, et au risque de paraitre meprisant (ce qui n'est pas le but), le
> developpement web a beaucoup evolue depuis rails 2.
> Les ignominies telles que le rjs ont disparu, et, bien que les helpers de
> vues rails supportent toujours des "options ajax", c'est vivement recommande
> de ne pas les utiliser (je recommande meme vivement de ne pas utiliser rails
> pour faire du rendering, a part json). Exit asset pipeline aussi.
> De meme, l'idee d'un serveur qui sert un document html qu'on "enrichi" par
> la suite avec du js et du css est bien morte. Du moins, pour ce qui concerne
> les applications web.
>
> Ca depend evidemment du type de projet que tu developpes mais pour eviter
> les problemes sur le long terme, c'est mieux d'avoir un backend qui ne
> retourne que du data et nessaie pas de manipuler l'etat du client.
>
> Les technos frontend sont maintenant tres matures et essayer de les piloter
> en ruby (via la pipeline, ou des taches rake) est une tres mauvaise idee
> aussi.
> Donc bye pipeline, bonjour webpack + react / ember.
pour faire du HTML et le HTML ne mourrera pas. Ne serait-ce que pour
le SEO.
Je voudrais pas que ce propos soit considéré comme une réalité.
Développer séparément son frontend de son backend entraine aussi un
surcout de temps.
--
Cyril Mougel
http://blog.shingara.fr
Florian Dutey
Feb 12, 2016, 10:14:20 AM2/12/16
to rails...@googlegroups.com
Bien sur que c'est de l'opinion perso. J'ai jamais pretendu exprimer l'opinion de quelqu'un d'autre.
On peut en debattre.
J'ai cependant precise "en ce qui concerne les applis web", en opposition a "site web", donc le SEO n'est pas sense etre un probleme. React sait tres bien gerer les problematiques de SEO, donc les technos frontend ne sont pas non plus un obstacle a ce niveau la. Au pire, une instance node et tu fais du server side rendering de tes composants, ca marche tres tres bien, on l'utilise tous les jours (je bosse pour un website builder et nos rendering de page sont faites en react).
Quand au surcout de temps, il faut prendre en compte le cout de faire mais aussi celui de ne pas faire, ie: la maintenance, les tests et les evolutions futures.
Si t'as un projet one shot, petit budget, scope reduit, avec une interface "debile", ca vaut ptet pas le cout d'investir dans une stack frontend. Par contre, des que t'as de l'application avec differents composants et des etats, ca devient tres interessant. Si le projet doit etre maintenu et evolue, ca prend encore plus de sens. Tester des rjs, ou du "observe_field" c'est juste infernal, meme avec selenium & friends. Tester automatiquement du react (ou meme du ember) c'est 1 milliard de fois plus simple et maintenable. Du coup, le cout d'assurance "anti-regressions" diminue largement.
Si tu as plus d'un client (appli IOS / android / windows phone etc), considerer ton FE comme un client parmi tant d'autres fait aussi beaucoup de sens, plutot que de dev tous tes controllers en double: 1 pour l'api, 1 pour le html. Les couts de bande passante du html peuvent entacher les perfs de l'api et il c'est plus complique de balancer la charge entre les 2 ... bref, t'as tellement de benefices a avoir un serveur agnostique des que ton projet le justifie. Et y'a pas beaucoup de projets qui le justifient pas SELON MOI.
Enfin, le but etait simplement de signaler qu'il existait depuis rails 2 d'autres outils de developpement pour les clients web, plus modernes et plus adaptes a certaines (beaucoup... SELON MOI) de situations. Ca concerne aussi la pipeline qui, en son temps etait bien utile, mais maintenant fait de la peine a cote des outils tels que webpack ou brocolijs et assimiles.
Bisous
--
--
Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups.
Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse rails...@googlegroups.com
Pour résilier votre abonnement envoyez un e-mail à l'adresse railsfrance...@googlegroups.com
---
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance.
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse railsfrance...@googlegroups.com.
Pour plus d'options, visitez le site https://groups.google.com/d/optout .
Sylvain Abélard
Feb 14, 2016, 5:40:36 AM2/14/16
to Railsfrance
Salut,
merci à chacun d'entre vous pour les points de vue complémentaires et argumentés.
Plus pragmatiquement pour ziburudebian :
- observe_field est bien mort (et tant mieux)
- on ne t'oblige pas à passer direct à une API back Rails et une appli front JS MVC
Bref, on te recommande vivement :
1. de passer à un peu de jQuery et render astucieux dans tes contrôleurs
pour conserver ta fonctionnalité iso au plus vite et avancer pour tes clients
(il est illusoire d'espérer un retour de RJS dans Rails depuis un bon moment)
2. dans un second temps ou en parallèle, de préparer une migration Rails 4
- Rails 2 vers Rails 3 est un peu douloureux (je crois me rappeler que tu as des scripts d'aide à la migration)
- mais ensuite 3->4 et 4->5 sont plus simples car Rails "casse" finalement peu de fonctionnalité
=> je suppose que passer de 2 à 4 direct c'est pas plus dur que 2->3 et 3->4 :
(mets bien tes tests pour t'assurer de refactorer sans peur -- j'ai conscience que c'est là aussi tout un pan de méthode et expertise)
3. pause bien mérité et... profite ! Tu vas gagner un tel boost en perf avec les nouvelles versions de Ruby et Rails, et en simplicité de code ;)
4. tu découvriras lors de cette migration et avec un peu de curiosité si le conseil de Florian a du sens pour toi et ton contexte
En fonction de ton niveau d'expertise sur Ruby, Rails, le Web et les archis ça peut être plus ou moins dur, n'hésite pas à poser tes questions ici une par une.
Bon courage et à bientôt !
merci à chacun d'entre vous pour les points de vue complémentaires et argumentés.
Plus pragmatiquement pour ziburudebian :
- observe_field est bien mort (et tant mieux)
- on ne t'oblige pas à passer direct à une API back Rails et une appli front JS MVC
Bref, on te recommande vivement :
1. de passer à un peu de jQuery et render astucieux dans tes contrôleurs
pour conserver ta fonctionnalité iso au plus vite et avancer pour tes clients
(il est illusoire d'espérer un retour de RJS dans Rails depuis un bon moment)
2. dans un second temps ou en parallèle, de préparer une migration Rails 4
- Rails 2 vers Rails 3 est un peu douloureux (je crois me rappeler que tu as des scripts d'aide à la migration)
- mais ensuite 3->4 et 4->5 sont plus simples car Rails "casse" finalement peu de fonctionnalité
=> je suppose que passer de 2 à 4 direct c'est pas plus dur que 2->3 et 3->4 :
(mets bien tes tests pour t'assurer de refactorer sans peur -- j'ai conscience que c'est là aussi tout un pan de méthode et expertise)
3. pause bien mérité et... profite ! Tu vas gagner un tel boost en perf avec les nouvelles versions de Ruby et Rails, et en simplicité de code ;)
4. tu découvriras lors de cette migration et avec un peu de curiosité si le conseil de Florian a du sens pour toi et ton contexte
En fonction de ton niveau d'expertise sur Ruby, Rails, le Web et les archis ça peut être plus ou moins dur, n'hésite pas à poser tes questions ici une par une.
Bon courage et à bientôt !
Simon Courtois
Feb 14, 2016, 9:00:57 AM2/14/16
to railsfrance
Hello,
En ce qui concerne la migration de versions, tu peux t'aider de synvert qui convrti pour toi pas mal de petites chose (appels d'activerecord, callbacks, etc). C'est très pratique :-)
Reply all
Reply to author
Forward
0 new messages