PHP, vos astuces pour palier à ses défauts ?

[niahoo]

Par moments, il est dommageable de devoir penser son code autrement pour pouvoir se passer de ce besoin.

[srm]

Sans aucun doute, comme beaucoup de choses quand tu utilises le langage PHP et que tu le compares à un langage très très expressif du genre Scala

[Hideaki]

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.

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 ...

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]

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.

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 ...

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

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

Je ne suis pas d'accord. La stack Java est tellement énorme (JMS, JPA, EJB, etc.) que justement, c'est bien une technologie qui te masque la technique sous-jacente.

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.

À 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).

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.


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.

Le truc, c'est que seule une infime portion des applications justifient l'utilisation de telles solutions. Pour les autres, c'est overkill.

[Hideaki]

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.

Je suis d'accord que tu l'utilises dans ta vue sans soucis avec facilité etc cependant tu ignores le traitement en interne pour te faciliter le travail c'est ce dont je te parlais. La facilité d'écriture est complétement différent du mécanisme en interne

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é ).

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.

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.

Le but de tous framework est de te masquer le travail et de te rendre l'utilisation plus simple et rapide à mettre en place.

À 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).

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.

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.

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

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.

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.

Le truc, c'est que seule une infime portion des applications justifient l'utilisation de telles solutions. Pour les autres, c'est overkill.

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 )

[Sephi-Chan]

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é ).

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.

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.

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.

Une anecdote pour la petite histoire, certains fragments de code se sont révélés plus rapides en Java ou en Python que leur équivalent en C.

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.

Je parlais des problématiques spécifiques aux entreprises : programmation distribuée, haute scalabilité, interfaçage avec des systèmes/services spécifiques (type banques, tour-opérateurs, etc.) et compagnie.

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

Effectivement, c'était trop tentant. Prenons donc cet exemple.

J'ai recherché des médecins dans l'Essonne. Je suis arrivé sur la page : http://www.pagesjaunes.fr/trouverlesprof...portail=PJ… Si tu suis ce lien, tu n'auras pas les résultats que j'ai eu. C'est mauvais pour l'expérience utilisateur et ça n'est pas REST du tout.

Bien sûr, le lien vers la deuxième page de résultats est également abscons et tu ne peux pas le suivre non plus : http://www.pagesjaunes.fr/trouverlesprof...portail=PJ…

Et si je trie les résultats : http://www.pagesjaunes.fr/trouverlesprof...portail=PJ

Ensuite, j'ai choisi le premier résultat de la liste. À cause du défaut précédemment cité, tu ne peux pas savoir de quoi il s'agit mais je suis sympa, je te donne le lien de la page : http://www.pagesjaunes.fr/trouverlesprof...portail=PJ… Au moins, tu peux suivre celui-ci.

J'aurais deviné tout seul que c'était un site écrit en Java.

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.

Je suis parfaitement conscient de ça. Mais là aussi, c'est souvent trop et inutile.

Java supporte les persistence unit, les data-sources, etc. Mais est-ce qu'un mec qui veut faire un jeu par navigateur a forcément besoin de ça ? Parce que c'est pénible à définir, ces petites bêtes, surtout dans ces horribles fichiers de configuration en XML…

Comme Java doit gérer ces cas, on impose à ceux qui n'ont pas de tels besoins d'utiliser ces notions parfois complexes.

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 )

Je suis tout à fait conscient que Java est très utilisé, que c'est une institution en entreprise, que ça permet de tout faire. Ce n'est pas pour autant qu'il est toujours le meilleur choix.

Quelles autres technologies connais-tu suffisamment pour dire qu'un projet serait de meilleur qualité et plus évolutif en Java/Dotnet ?


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.

Si je devais conclure, je conseillerais de toujours s'intéresser à d'autres technologies. Ce n'est pas parce qu'on aime une technologie qu'il ne faut pas lui porter un regard critique et regarder ailleurs.

[niahoo]

tu m'as déjà fait le coup des pages jaunes, quand je disais à peu près la même chose que sephi à propos de l'expérience utilisateur des sites en java. alors oui, les pages jaunes c'est classe, mais pour l'instant c'est le seul que j'ai vu

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é) ?

[Sephi-Chan]

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é) ?

Dans REST, on utilise POST pour effectuer une opération qui va altérer une ressource. Ça peut être la création et/ou la modifier, selon les choix de ceux qui implémentent l'API RESTful. L'authentification n'est pas une condition sine qua non.

Dans Rails, on utilise généralement POST pour créer une ressource et PUT pour la modifier.

Un exemple appliqué à un Webgame (ça change des CRUD à la con) : je souhaite déployer 2 unités sur un territoire qui m'appartient. Je vais envoyer une requête PUT à ma ressource Ownership (qui modélise l'appartenance d'un territoire à un joueur). Je créerais alors une route telle que :

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

Et le corps de la requête devra contenir un paramètre, disons count. Bien sûr, ce paramètre pourrait être donné en GET, mais l'intérêt serait moindre. Ainsi dans le code de mon contrôleur, j'ai un code très simple du type (ensuite, j'ai des vues pour répondre au formats souhaités : HTML, JSON ou autre) :

def deploy

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

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

  

  ownerships.deploy_units!(params[:count])

end

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.

Une autre possibilité pourrait être de traiter une recherche comme une ressource identifiée : avec ses propres résultats gravés dans le marbre (qui ne varieraient pas au cours du temps). Ainsi, la recherche est bien stateless. Après, la question à se poser : est-ce que ce besoin est pertinent ?

Ce n'est pas parce que REST présente certains avantages que c'est toujours la meilleure solution. Dans certaines de mes applications, j'ai une route /dashboard : ça n'a pas de sens d'un point de vue REST mais c'est fort utile. J'essaye d'utiliser les outils à ma disposition avec pragmatisme pour faire ce que je veux sans m'enfermer dans un carcan pénible.

[srm]

Le meilleur choix pour coder en Java/Scala est ... Play!

[niahoo]

Dans Rails, on utilise généralement POST pour créer une ressource et PUT pour la modifier.

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

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.

ben du coup c'est ce que font les pages jaunes ...

Est-ce que tous les navigateurs implémentent PUT et DELETE (dans leurs dernières versions + ie8) ?