en réponse à ta question Nicolas " Vu que tu débutes et apprends, fais le nécessaire pour passer rapidement sur Rails 3..." je développe avec radrails 2 seulement voila j ai un gros problème je n'arrive pas à crée de projet en rails 3.0.0 ou supérieure . si je crée le projet manuellement y a pas de probléme
* rails new test* *create * * create README* * create Rakefile* * create config.ru* * create .gitignore* * create Gemfile* par contre pour lancer le projet après il ne veux pas :'( * * Le 15 décembre 2010 23:53, Nicolas Blanco <[email protected]> a écrit : > Bonsoir et merci de poser la question. > > Donc pourquoi faut-il progressivement abandonner le RJS ? Voici ma > longue (mais détaillée) réponse... > > Il faut déjà bien comprendre ce que c'est le RJS. C'est en gros faire > une requête au serveur, et le serveur va répondre un bloc de JS généré > dynamiquement, avec des morceaux de vues à l'intérieur. Le client > reçoit ce gros morceau moche mélangeant HTML et JS et l'évalue. > > En fait, tout est une question de bonnes conventions. Il y a 10 ans, > cela ne posait pas de problème de mélanger les styles dans le code > HTML. > > Aujourd'hui c'est devenu un standard de séparer l'HTML des styles avec > des CSS... > > Progressivement, il en va de même pour le code côté client : les bons > développeurs Web ne mélangent plus le JS dans l'HTML, cela s'appelle > l'Unobtrusive JavaScript. > Fini les onclick="bidule", etc. Désormais, le code côté client est > scripté à part avec un framework Javascript type jQuery qui va binder > des événements sur les différents éléments de vues. > > Le gros phénomène actuel est que progressivement la logique se déplace > du côté client. Avec l'augmentation des performances des interpréteurs > JavaScript, les interfaces mobiles, les interfaces HTML offline, les > vues deviennent de plus en plus complexes. > > Des frameworks comme Sproutcore d'Apple ou Cappuccino déplacent > totalement la logique côté client et proposent des ensembles de > composants JavaScript indépendants. Ces composants communiquent > uniquement avec le serveur avec des appels JSON. En gros le serveur ne > fournit plus de vue après l'envoi de l'application initiale, il ne > fournit qu'une API qui va répondre au client avec du JSON. > > Donc ça c'était pour la tendance actuelle... En gros pour résumer, > actuellement une bonne manière de faire est de scripter des composants > d'interfaces indépendants et donc potentiellement réutilisables en > utilisant un framework JS (bas niveau : jQuery, plus haut niveau par > exemple Backbone.js). Et s'il doit y avoir communication entre les > composants et le serveur, cela se fait via des appels REST avec un > retour en JSON. > > -- > Nicolas Blanco, Web developper > > http://www.nicolasblanco.fr > Jabber/GoogleTalk : [email protected] > Twitter : http://twitter.com/slainer68 > Github : http://github.com/slainer68 > Skype : slainer68 > > -- > 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 > [email protected] > Pour résilier votre abonnement envoyez un e-mail à l'adresse > [email protected] > -- 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 [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected]
