PHP, vos astuces pour palier à ses défauts ? - Version imprimable +- JeuWeb - Crée ton jeu par navigateur (https://jeuweb.org) +-- Forum : Discussions, Aide, Ressources... (https://jeuweb.org/forumdisplay.php?fid=38) +--- Forum : Programmation, infrastructure (https://jeuweb.org/forumdisplay.php?fid=51) +--- Sujet : PHP, vos astuces pour palier à ses défauts ? (/showthread.php?tid=5696) |
RE: PHP, vos astuces pour palier à ses défauts ? - Hideaki - 20-09-2011 Citation :Il me semble nécessaire d'éclaircir un point. En Ruby, @foo est l'équivalent de this->foo en Java. Il n'y a pas de mécanisme sous-jacent de mapping.Désolé mais c'est du php en gros tu me dis que à chaque requête une nouvelle action/controleur est créé ? Citation :Pourtant, presque aucun site n'est écrit en C. Pourquoi ? Parce que c'est l'accès aux données qui ralentit une application, pas la vitesse d'exécution du code. Une lecture intéressante : Numbers everybody should know.Je ne parlais des accès aux données ... Citation :Effectivement, c'était trop tentant. Prenons donc cet exemple.Ce n'est pas un problème lié au langage mais un choix de conception, lié entre autre à une obligation légale, mais cela tu ne pouvais pas le savoir Citation :Je suis parfaitement conscient de ça. Mais là aussi, c'est souvent trop et inutile. Si tu n'aimes pas les fichiers xml tu peux utiliser un fichier de configuration classique, effectivement si tu dois utiliser toutes les capacités proposés cela peut être complexe mais pour le standard cela représente que deux ou trois lignes. Citation :Pour développer un Webgame, je doute que le choix de Java EE ou Spring soit pertinent. De nombreuses autres outils permettent de développer plus simplement et plus rapidement : Play (du Java, donc), Rails (Ruby), Symfony (PHP), Zend Framework (PHP), etc.Pour un amateur, je lui conseillerais le php pour entre autre le facilité de trouver un hébergement peu cher, après concernant la facilité tu te trompes, il est simple et rapide de développer en java, vu que l'on utilise d'autre chose que celle proposé lors des études pour faire le prototypage du projet et la structure interne comme pour les autres techno que tu proposes ... j'ai testé play mais pas aimé et je préfère Symfony à Zend. @niahoo : un autre exemple aol.com ( c'est la deuxième fois que j'écris le message, fermeture de navigateur donc j'ai été plus bref que mon premier essai ) RE: PHP, vos astuces pour palier à ses défauts ? - srm - 20-09-2011 En vrai REST : POST = new PUT = edit RE: PHP, vos astuces pour palier à ses défauts ? - niahoo - 20-09-2011 Mais y a une doc REST "officielle" ? Ton navigateur hideaki il est écrit en Java ? RE: PHP, vos astuces pour palier à ses défauts ? - srm - 20-09-2011 Ne pas aimer Play! ? Curieux... RE: PHP, vos astuces pour palier à ses défauts ? - Hideaki - 20-09-2011 @niahoo j'utilise opéra et j'ai cliqué sur le petite croix au lieu de fermer un onglet, c'est tout RE: PHP, vos astuces pour palier à ses défauts ? - niahoo - 20-09-2011 je blague :=) Sur opera j'utilise les mouse gestures, c'est pratique et tu es sûr de ne pas te tromper. j'ai également mis la barre d'onglets en bas voilà et surtout C^W pour fermer un onglet RE: PHP, vos astuces pour palier à ses défauts ? - Hideaki - 21-09-2011 c'est que j'ai pensé plus besoin de la page je ferme et paf l'instinct à fermer le navigateur au lieu de l'onglet, vu que je m'entraine à un certain rts j'ai cliqué plus vite que mon ombre x) RE: PHP, vos astuces pour palier à ses défauts ? - Sephi-Chan - 21-09-2011 (20-09-2011, 10:04 PM)niahoo a écrit : Mais y a une doc REST "officielle" ? C'est Roy Fielding qui a introduit la notion de REST dans sa thèse Architectural Styles and the Design of Network-based Software Architectures (20-09-2011, 09:58 PM)niahoo a écrit : marrant c'est l'inverse dans une DB http que j'utilise. (d'ailleurs ça me parait plus logique: PUT pour poser une nouvelle ressource, POST pour envoyer des termes de recherche C'est ce dont je parlais. Je crois me souvenir que Riak ne fait pas comme les autres au niveau des méthodes. Après, tant que c'est cohérent, je ne vois pas de problème. (20-09-2011, 09:58 PM)niahoo a écrit :(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. Non. Quand je fais une recherche, je ne peux pas t'envoyer l'URL de la page de résultat pour que tu puisses les regarder. Pages Jaunes n'est pas REST du tout. (20-09-2011, 09:58 PM)niahoo a écrit : Est-ce que tous les navigateurs implémentent PUT et DELETE (dans leurs dernières versions + ie8) ? Je ne parviens pas à trouver cette information. Du coup beaucoup de systèmes utilisent l'approche de Rails, à savoir que les requêtes DELETE et PUT sont en fait des requêtes POST mais qui portent un paramètre qui contient le nom de la méthode à utiliser vraiment (dans Rails, ce paramètre s'appelle _method). (20-09-2011, 09:59 PM)Hideaki a écrit :Citation :Il me semble nécessaire d'éclaircir un point. En Ruby, @foo est l'équivalent de this->foo en Java. Il n'y a pas de mécanisme sous-jacent de mapping.Désolé mais c'est du php en gros tu me dis que à chaque requête une nouvelle action/controleur est créé ? Quelle mauvaise foi… Je suis certain que tu as très bien compris. Et j'espère que tu as également compris qu'il n'y avait pas de mécanisme de map comme en Java, donc plus de simplicité et moins de pertes. A chaque requête, le routeur détermine quel contrôleur doit être instancié et quelle action doit être appelé dessus. (20-09-2011, 09:59 PM)Hideaki a écrit : Ce n'est pas un problème lié au langage mais un choix de conception, lié entre autre à une obligation légale, mais cela tu ne pouvais pas le savoir Pardon mais cette façon de balayer mon commentaire sonne encore la mauvaise foi… Quelle genre d'obligation légale ? C'est interdit d'avoir des URL propres en Java EE ? Ou alors c'est mettre les paramètres de la recherche dans la requête qui est interdit ? (20-09-2011, 09:59 PM)Hideaki a écrit : Pour un amateur, je lui conseillerais le php pour entre autre le facilité de trouver un hébergement peu cher, après concernant la facilité tu te trompes, il est simple et rapide de développer en java, vu que l'on utilise d'autre chose que celle proposé lors des études pour faire le prototypage du projet et la structure interne comme pour les autres techno que tu proposes ... j'ai testé play mais pas aimé et je préfère Symfony à Zend. Choisir une technologie parce qu'elle est facile à héberger sur du mutualisé, c'est vraiment la loose. Quand on développe un projet sérieux, on peut investir 200€ par an pour louer un dédié/paas qui fait sauter les barrières technologiques et qui permet de choisir les technologies pour leurs qualités intrinsèques. Bien sûr que tu trouves que développer en Java est facile : c'est ta techno préférée. Mais j'aurais aimé que tu répondes à ma question concernant les autres technologies Web que tu maîtrises bien. RE: PHP, vos astuces pour palier à ses défauts ? - niahoo - 21-09-2011 (21-09-2011, 06:47 AM)Sephi-Chan a écrit :(20-09-2011, 09:58 PM)niahoo a écrit :(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. C'est contradictoire. Si garder les paramètres de recherche dans l'URL ce n'est « pas REST » alors dans Rails tu les enverra par POST. Et dans ce cas, à moins de générer des token, ce dont nous n'avons pas parlé, ton URL de résultats sera /search ou /search-results et donc pas possible non plus de passer l'URL à quelqu'un pour qu'il tombe sur les résultats. Sinon avec un token (comme sur ce forum il me semble) je pige mieux. RE: PHP, vos astuces pour palier à ses défauts ? - Sephi-Chan - 21-09-2011 (21-09-2011, 09:24 AM)niahoo a écrit :(21-09-2011, 06:47 AM)Sephi-Chan a écrit :(20-09-2011, 09:58 PM)niahoo a écrit :(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. Il y a eu un malentendu. On brise REST quand on ajoute une notion d'état dans la requête, pas quand on utilise des paramètres dans l'URL. Je ne pense pas que la composante temps brise REST. Prenons une requête Google : http://www.google.com/search?q=hornet. Elle n'est pas vraiment REST puisque Google arrange les réponses si on est identifié pour améliorer la pertinence : si je tape Hornet, les résultats parlerons de moto, alors que si j'étais fan d'insectes, ça parlerait de frelons. Si je trouve le moteur de recherche des Pages Jaunes mauvais, ce n'est pas parce qu'il n'est pas RESTful mais parce que la page de résultat est accessible en POST. On ne peut donc pas donner le lien à quelqu'un pour qu'il aille voire, comme je viens de le faire pour ma recherche Google. Je doute qu'un moteur de recherche puisse être RESTful, ça n'aurait pas vraiment de sens. |