Sephi-chan a écrit :Et il n'y a pas d'ajout de paramètre pour rien, si j'avais défini @hotel au lieu de hotel, ça ne m'aurait pas coûté plus cher.

Sephi-chan a écrit :La vue peut accéder à ces variables d'instance.

Sephi-chan a écrit :Selon moi, les outils proposés par Java poussent les développeurs à compliquer inutilement les choses. Et c'est justement cette incitation à la simplicité qui m'a séduit dans Rails.

(20-09-2011, 12:57 PM)Hideaki a écrit :

Sephi-chan a écrit :Et il n'y a pas d'ajout de paramètre pour rien, si j'avais défini @hotel au lieu de hotel, ça ne m'aurait pas coûté plus cher.

Sephi-chan a écrit :La vue peut accéder à ces variables d'instance.

Mais sais-tu ce qui se passe lors de l'interprétation/compilation du code ? L'interpréteur ne va pas vérifier si dans la page généré cet attribut est utilisé, par conséquent, il est dans l'obligation de créer un mapping ou tableau contenant la clef ( le nom de ta variable désigné par @ ) et la valeur associée afin de la transmettre à ta vue, cette création nécessite certaine manipulation spécifique qui prend un certain temps qui est négligeable mais dans le cas d'une forte sollicitation ...

(20-09-2011, 12:57 PM)Hideaki a écrit :

Sephi-chan a écrit :Selon moi, les outils proposés par Java poussent les développeurs à compliquer inutilement les choses. Et c'est justement cette incitation à la simplicité qui m'a séduit dans Rails.

L'avantage ici avec J2ee mais aussi dans d'autre langage, c'est que le processus n'est pas masqué et permet donc de mieux prendre conscience de ce fonctionnement. La simplicité est souvent le contraire de l'optimisation, tu as dû déjà voir le cas en C

Sephi-chan a écrit :Tu n'arrives pas à imaginer que Rails agisse différemment de JEE… Dans les actions, je définis des attributs et j'y ai accès dans la vue. Ni plus, ni moins.

Sephi-chan a écrit :Traiter un problème de manière simple, c'est utiliser une technique qui fait juste ce qu'il faut. C'est généralement plus performant.

Sephi-chan a écrit :À l'inverse, les frameworks Web Java — parce qu'ils s'adressent à un public professionnel amateur de problématiques ultra spécifiques — apportent des solutions qui sont plus complexes que nécessaire dans la majorité des cas (à savoir les problématiques simples, les plus nombreuses).

Sephi-chan a écrit :Voilà pourquoi beaucoup d'applications Web écrits en Java sont des bloatwares. D'ailleurs, un site en Java se reconnaît facilement : des URL moches à rallonge, un code HTML pourri, etc.

Sephi-chan a écrit :Je suis convaincu que Java, et plus généralement la JVM, est excellente : l'écosystème permet de gérer tous les besoins du monde. Cet atout a un prix : la complexité. Quand on veut gérer tous les cas, il faut multiplier les couches, les composants, etc. Ça a un coût.

Sephi-chan a écrit :Le truc, c'est que seule une infime portion des applications justifient l'utilisation de telles solutions. Pour les autres, c'est overkill.

(20-09-2011, 06:23 PM)Hideaki a écrit : Je ne te parlais pas du stack de java, mais soulignait juste que ce que fait le traitement en interne pour ruby était directement visible en j2ee pour ce cas là et si tu ne fais attention aux déclaraction @NomVariable cela pourrait-être un gouffre en ressource et pour rien ( dans le cas mentionné ).

(20-09-2011, 06:23 PM)Hideaki a écrit : Ce que je voulais dire c'est que plus tu utilises un outil ou technologie ta facilitant ainsi le travail, mois le code peut être performant, plus tu utilises une techno de haut niveau ( au sens d'abstraction ) plus le code à exécution est lent, un code en C sera forcément plus rapide qu'un langage de plus haut niveau.

(20-09-2011, 06:23 PM)Hideaki a écrit : J'ignore l'expérience que tu as eu mais un REST avec JPA est très simple à mettre en place. Je ne vois pas ce que tu appelles les problèmes spécifiques, si c'est pour faire autre chose qu'un blog effectivement se sont des problèmes spécifiques.

(20-09-2011, 06:23 PM)Hideaki a écrit : Si tu le dis ... mais je doute que tu ailles assez d'expérience pour en jugé voici un site http://www.pagesjaunes.fr/ URL n'est pas moche, le code HTML clean, etc mais c'est du j2ee !!! Désolé mais c'était trop tentant

(20-09-2011, 06:23 PM)Hideaki a écrit : On utilise plusieurs couches afin de ne pas être dépendant, permettre de transformer une application existante en WebService rapidement, changer de framework sans refaire l'ensemble des couches etc, pour les composants c'est vraiment dépendant du projet et des choix technologiques etc et cela n'est pas spécifique à un langage particulier, évidement que tout à un coût après tout est une question de choix perdre du temps à écrire du code alors que des solutions existent déjà etc, cela n'empêche pas de faire attention à la manière d'utiliser les "raccourcis" proposer quelques soient le langage.

(20-09-2011, 06:23 PM)Hideaki a écrit : Il est certain que pour faire un simple site, blog ou autre nul besoin de cette technologie en revanche pour des projets de plus grande importance celui-ci est préférable, un projet java ou .net offre bien souvent une qualité et une évolution bien plus intéressante que qu'autres langages dû notamment à son écosystème, bien plus d'application que tu crois utilise la technologie java ( au sens large )

(20-09-2011, 08:51 PM)niahoo a écrit : Une remarque par rapport à ce que dit Sephi : les URL REST c'est bien, mais dans une appli Rails, les termes de la recherche sont donc envoyés en GET systématiquement afin de pouvoir bookmark la parge de résultats ?
Dans quel cas préconise-t'on l'envoi via POST ? Uniquement pour les interfaces auxquelles il faut être loggés (espace privé) ?

put "/games/:game_id/ownerships/:id/deploy", to: "ownerships#deploy"

def deploy

  game      = Game.find(params[:game_id])

  ownership = game.ownerships.find(params[:id])

  

  ownerships.deploy_units!(params[:count])

end

(20-09-2011, 09:22 PM)Sephi-Chan a écrit : Dans Rails, on utilise généralement POST pour créer une ressource et PUT pour la modifier.

(20-09-2011, 09:22 PM)Sephi-Chan a écrit : Dans le cas d'un moteur de recherche, les paramètres utiles pourraient en effet être transmis inscrits dans l'URL mais ça ne serait pas REST puisqu'on conserve la composante temps : les résultats d'une même recherche peuvent varier au cours du temps.