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

[Hideaki]

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

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.

Je ne parlais des accès aux données ...

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.

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

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.

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.

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.

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 )

[srm]

En vrai REST :
POST = new
PUT = edit

[niahoo]

Mais y a une doc REST "officielle" ?

Ton navigateur hideaki il est écrit en Java ?

[srm]

Ne pas aimer Play! ?
Curieux...

[Hideaki]

@niahoo j'utilise opéra et j'ai cliqué sur le petite croix au lieu de fermer un onglet, c'est tout

[niahoo]

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

[Hideaki]

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)

[Sephi-Chan]

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

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.

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

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.

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

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.

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 ?

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.

[niahoo]

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

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.

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.

[Sephi-Chan]

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

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.

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.

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.