Ernestine

Bonjour et bienvenue

Le plus simple serait que tu nous donnes l'adresse de ton blog pour qu'on regarde à quoi ressemble ton captcha. Parce qu'un captcha qui laisse passer 50 spams par semaine, soit il est particulièrement facile à contourner, soit il est mal réglé, mais en tous cas, il y a quelque chose de louche là-dedans.

Peut-être devrais-tu aller sur le site de France-map, et mettre à jour (voire réinstaller) ta carte, ou au pire, leur poser la question, ce sont eux qui sont les plus à même de te répondre.

Bonjour, Tu dois échapper les données avec la fonction mysql_real_escape_string : $requete3 = "SELECT * FROM ".$table." WHERE activite='".mysql_real_escape_string($libelle)."'"; Non seulement ça règlera ton problème d'apostrophe, et de plus, c'est indispensable pour la sécurité.

Bonjour, Les deux solutions sont parfaitement équivalentes, pour le visiteur (en l'ocurence Google bot) c'est transparent, puisque dans les deux cas la réponse du serveur est exactement la même. Donc le mieux, c'est effectivement de choisir la solution la plus simple pour toi

Bonjour Iwi, bienvenue

En flash ou en javascript, je pense que le temps de développement sera à peu près équivalent (pour quelqu'un qui sait développer en javascript), donc autant le faire en javascript, ce sera quand même bien plus accessible, et surtout ça évitera de se priver de tous les utilisateurs qui ne peuvent pas ou ne veulent pas installer le plugin flash Il existe de nombreux plugins javascript pour le traitement d'images (resizing, croping, etc) et le positionnement (glisser-déposer, inverser, etc) Rien qu'en combinant les plugins de jQuery User Interface (http://jqueryui.com/) tu peux déjà faire presque tout ce dont tu as besoin pour tes parchemins. Mais au final, ça revient quasiment à développer un éditeur de texte, ton truc

Bonjour, En fait, l'utilisateur doit pouvoir ajouter autant d'images qu'il veut, les positionner comme il le veut sur l'image de fond, et aussi les redimensionner, de même il doit pouvoir ajouter des blocs de texte et les placer où il veut ? Et au final, il faut que le serveur enregistre tout ça sous la forme d'une image parchemin ? Ca me paraît quand même un peu compliqué, ça m'étonnerait que tu trouves un script qui fasse tout ça. Ou alors, solution un peu bancale : proposer un éditeur de texte javascript, qui permet de mettre en forme textes et images. Mais bon. Le plus simple selon moi serait que tu définisses un cadre plus strict pour les parchemins : un nombre limité de photos, et un nombre limité de blocs de texte, avec, pour les organiser visuellement, un choix entre trois ou quatre templates différents.

Peut-être que la requête ne s'effectue pas correctement. Tu peux remplacer $resource = mysql_query($sql); par $resource = mysql_query($sql) or die(mysql_error()); Comme ça, si une erreur s'affiche, c'est que quelque chose ne va pas (et tu sauras précisément d'où vient l'erreur). Par ailleurs, avant de faire ta requête en php, il serait préférable que tu l'écrives directement en SQL pour la tester : c'est plus facile, et au moins, une fois que c'est fait, c'est une grosse partie du problème de résolu. Pour cela, dans phpmyadmin, tu cliques sur l'onglet SQL et tu tapes ta reqête, ce qui devrait donner : SELECT * FROM table WHERE ville IN (SELECT ville FROM table WHERE round(juin, 0)=30 AND code=203) Comme ça, tu verras tout de suite si ça fonctionne ou pas. Si ça fonctionne, tu verras clairement à quoi ressemble le tableau de réponse, et si ça ne fonctionne pas, le message d'erreur est en général très explicite.

Mettre les blocs noir et bordeaux en float left et right ne marchera pas puisqu'ils doivent s'étendre à l'infini selon la largeur de l'écran. Cela dit, pas la peine de considérer "l'infini" en largeur d'écran : rares sont les écrans de plus de 1900 pixels, on peut donc se baser sur cette dimension (voire un peu plus pour être tranquille) pour tout ce qui est élément décoratif style image de background. D'après ce que je comprends, tes blocs noir et bordeaux sont purement décoratifs : tout le contenu sera dans le bloc jaune. Dans ce cas, plutôt que de multiplier les divs, tu pourrais te contenter de faire un seul div jaune. Et pour le style du body tu mettrais : body { background: url(body.jpg) center top repeat-y; } Où body.jpg serait une image de 1900 pixels de large et 1 pixel de haut, noir dans sa moitié gauche et bordeaux dans sa moitié droite. Ainsi, en une seule ligne, tu recrées l'illusion de tes deux blocs de gauche et de droite. Et à partir de là il devient facile de mettre le bloc jaune (avec un margin: auto; et une largeur fixe pour le centrer), le bleu et le vert. Ceci n'est évidemment qu'un exemple à adapter. Et puis, comme dit précédemment, il y a des milliers de façons de résoudre ton problème. Je suppose que les deux colonnes noir et bordeaux ne contiendront pas une seule couleur, qu'il y aura des "éléments décoratifs" à l'intérieur, style bas de colonne, dégradés, arrondis, etc... Mais de façon générale, essaie vraiment de minimiser le nombre de blocs. Si tu nous montrais la maquette finale, ce serait plus facile de t'aiguiller, car sans savoir si les différents blocs contiennent des éléments, ou sont là juste pour décorer, ou s'ils ont des coins arrondis en bas, etc, tous ces détails, difficile de dire quelle est la meilleure solution.

Bonsoir, Il y a des dizaines de façons de faire ça, tout dépend à quoi vont servir les différents blocs. A priori comme ça, à première vue, il s'agit d'un design sur trois colonnes. Dans ce cas, plutôt que de faire un bloc jaune qui vient par dessus les deux autres, il vaut mieux faire le bloc noir en float:left, le bloc bordeaux en float:right, et le bloc jaune en normal, de manière à ce qu'il se situe naturellement entre (et non pas sur) les deux autres blocs. Quant au bloc vert, vue sa position, le plus simple serait sans doute de le positionner en absolute. Et pour le bloc bleu ciel, rien de particulier. Le plus compliqué avec des designs sur plusieurs colonnes, c'est de s'arranger pour que l'ensemble des blocs descende bien jusqu'en bas de page, ou du moins donne l'illusion de descendre jusqu'en bas de page. S'ils sont de hauteur variable, ça ne se fait pas naturellement, il faut ruser (il y a plusieurs façons pour le faire). Tu peux déjà commencer par lire ce tutoriel : http://www.alsacreations.com/tuto/lire/588-trois-colonnes-float.html

Bonjour, Soit je n'ai rien compris à ce que tu veux faire, soit tu t'y prends très mal. Parce que là, j'ai l'impression que toutes tes requêtes pourraient être réalisées en une seule. Pourrais-tu expliquer clairement (pas la peine de copier du code) ce que tu veux faire sur cette table ?

Bonjour, Il n'y a aucune raison que ça plante sous prétexte qu'il y a des apostrophes. A mon avis, c'est que tes données sont mal enregistrées dès le départ. Pour bien enregistrer les données, il faut les insérer avec mysql_real_escape_string(), pour échapper apostrophes, guillemets, etc. Il faut aussi s'assurer que le serveur n'ajoute pas lui-même des slashes sur les données de formulaire, ce qui est généralement le cas sur les serveurs mutualisés, car pour des raisons de sécurité le paramètre magic_quotes_gpc est à On, auquel cas il faut d'abord supprimer ces slashes avec stripslashes() et ensuite faire l'inclusion avec mysql_real_escape_string().

Bonjour et bienvenue

Ce que tu fais n'est pas du tout logique : tu fais trois redirections permanentes à partir d'une unique page ! La meilleure méthode pour ton référencement, c'est de ne pas créer de page index_fr.html, mais uniquement les deux autres, c'est à dire : - conserver index.php pour la version française (donc pas question de créer un index_fr.html) - créer index_en.html pour la version anglaise - créer index_it.html pour la version italienne Et là il n'y a aucune redirection à faire : tu as juste à placer des liens vers chacune des versions sur les pages d'accueil. Ainsi, Google continuera d'indexer la page française comme il l'a toujours fait (index.php), et indexera les deux autres versions lors de ses prochaines visites. Par ailleurs, pour rediriger vers la bonne langue, tu ferais mieux de faire ça par détection de la langue du navigateur, plutôt que par l'adresse ip. Mais le mieux est de ne pas faire de détection automatique, et laisser les visiteurs choisir. C'est aussi préférable pour le référencement.

Bonjour, Parmi les recettes de grand-mère pour lutter contre le spam de formulaire, il y a aussi la technique du champ caché en CSS : <input type="text" id="truc" name="truc" /> input#truc { position: absolute; left: -500px; top: -500px; } Un utilisateur qui navigue à l'écran ne verra pas cet input et ne le remplira donc pas. Tandis qu'un robot, en général, remplit bêtement tous les champs. Donc côté serveur, si le champ a été rempli : on ne valide pas. Et pour les utilisateurs qui naviguent en mode texte, oral, brail, etc, on pourra faire précéder l'input d'un label du style : <label for="truc">Ne remplissez pas ce champ</label> (label également masqué en CSS). Mais bon, c'est loin d'être super fiable, pas plus que les autres techniques excepté le captcha. Je crois que désormais, bien souvent, les spammeurs viennent d'abord physiquement sur le site web à spammer afin de déblayer le terrain manuellement et voir comment remplir le formulaire. Ensuite, leur robot prend le relais. En effet, j'ai vraiment vu des trucs incroyables. J'avais mis en place un captcha texte avec des petites énigmes du genre : "combien font 4 x 5", ou "dernière lettre du mot machin", etc... Eh bien j'ai eu la surprise, un jour, de voir qu'un robot arrivait à y répondre. J'ai donc changé la série d'énigmes, j'ai eu la paix une semaine ou deux, et puis ça a repris. Je pense que le coup des énigmes ne peut fonctionner que si ces énigmes sont générées de façon aléatoire, par exemple : où n est un chiffre tiré au hasard, et M un mot tiré au hasard dans une longue liste. Et encore, même ça, un spammeur humain peut créer un petit programme qui saura y répondre. Le coup de la session c'est pareil : rien n'empêche un robot d'accepter les cookies. Vérifier qu'il s'est passé au moins cinq secondes entre le remplissage du premier champ et l'envoi du formulaire ? Là encore, un humain peut facilement déblayer le terrain et programmer son robot pour faire ce qu'on attend de lui. Au final, malheureusement, je crois que jusqu'à aujourd'hui, la technique la plus fiable reste le captcha visuel (un code à recopier). D'un point de vue accessibilité c'est nul, mais c'est la méthode la plus efficace (et ce n'est même pas efficace à 100% car il existe des logiciels capables de détecter lettres et chiffres sur une image). PS : et pour Akismet, personnellement, je n'aime pas les filtres automatiques, qui se basent bien souvent sur la présence de tel ou tel mot clé. Il y a inévitablement des messages qui seront retenus par le filtre alors qu'ils étaient cleans.

Bonjour, Primo, il faut que tu utilises les balises code et /code pour inclure tes lignes de code dans ton message (comme sur n'importe quel forum) parce que là c'est juste illisible. Ensuite, je n'ai pas vraiment compris ton problème, si tu pouvais le reformuler de façon claire ce serait sympa, et surtout donner un exemple : - date entrée en paramètre (je suppose que ça doit être du style : '2011-10-15 20:10:35' c'est à dire un datetime mysql) - date erronée obtenue avec la fonction - date que tu voudrais obtenir si tout se passait bien A priori, vu comme ça, il n'y a aucune raison que ce code enlève ou ajoute deux heures...

Ah oui, j'ai oublié le point d'interrogation à la à la fin de la deuxième ligne (après page-%1.html), il suffit de faire : RewriteCond %{QUERY_STRING} ^page=(.*)$ RewriteRule ^Violet/violetmain\.php$ http://delafeuilledor.fr/page-%1.html? [L,R=301] RewriteRule ^page-(.+).html$ vdisplay.php?page=$1 [L] Ce qui dirigera vers une adresse du style page-atelier.html (qui elle-même pointera sur vdisplay.php?page=atelier) Pour ton autre demande, tu peux tout simplement faire les redirections une par une à la main, exemple pour la page atelier : RewriteCond %{QUERY_STRING} ^page=atelier$ RewriteRule ^Violet/violetmain\.php$ http://delafeuilledor.fr/page-atelier.html? [L,R=301] RewriteRule ^page-atelier.html$ vdisplay.php?page=atelier [L] En dupliquant ces trois lignes autant de fois que tu as de pages à rediriger, en remplaçant le mot "atelier" par les noms nécessaires

Bonjour, Pour le premier point, je pense que ceci devrait fonctionner : RewriteCond %{QUERY_STRING} ^page=(.*)$ RewriteRule ^Violet/violetmain\.php$ http://delafeuilledor/vdisplay.php?page=%1 [L,R=301] Pour le deuxième, ceci (c'est qu'un exemple à adapter, tu peux remplacer "page" par ce que tu veux) : RewriteRule ^page-(.+).html$ vdisplay.php?page=$1 [L] Et si tu veux combiner les deux, à savoir une redirection 301 de Violet/violetmain.php?page=truc vers page-truc.html qui redirige (sans 301) vers vdisplay.php?page=truc, il faut mettre : RewriteCond %{QUERY_STRING} ^page=(.*)$ RewriteRule ^Violet/violetmain\.php$ http://delafeuilledor/page-%1.html [L,R=301] RewriteRule ^page-(.+).html$ vdisplay.php?page=$1 [L] PS : et tu nous dis que ton .htaccess est actuellement vide, donc n'oublie pas d'ajouter au début : RewriteEngine On pour activer l'url rewriting.

Merci pour ces réponses, mais j'ai dû très mal m'exprimer car ce n'est pas vraiment ce que je demandais. Pour le premier point, ce que je voulais dire, c'est que sur le web (du moins avec php), tout se résume toujours à une seule et unique action de l'utilisateur. Le client envoie sa requête, le serveur effectue son traitement et envoie une réponse, et point final, les choses s'arrêtent là (l'utilisation des sessions permet d'avoir une sorte de continuité d'une action à l'autre, mais ça ne change pas grand chose au concept). Partant de là, je n'arrive pas à comprendre à quoi vont nous servir les objets. Alors que dans une application java ou C++, ces objets existent dans le temps, interagissent entre eux, sont modifiés, etc, jusqu'à fermeture de l'application, ou destruction par le programme ou ramassage par le garbage collector peu importe. Dans le deuxième cas, je vois bien l'intérêt, mais dans le premier, pour l'instant, je ne le vois pas. Quant au deuxième point, j'ai parfaitement compris le pattern MVC, que j'utilise depuis des années. C'est bien de l'objet que je parlais. Imaginons un objet $message, instance de la classe Message, qui contient un champ $contenu. J'aurai logiquement un setter setContenu($contenu). Mais les données de mon message, au fond, elles sont stockées dans la BDD. Dans un cours sur internet (mais c'était peut-être un mauvais cours), il est écrit que lorsque l'utilisateur modifie son message, je dois instancier un objet $message avec les données de la BDD, puis modifier cet objet (avec des méthodes du genre setContenu()). Ok je veux bien, mais après avoir fait mon $message->setContenu() il me faudra encore faire un update sur la BDD, donc je ne vois pas à quoi a servi l'objet $message au milieu de tout ça. A moins que l'update de la BDD se fasse carrément dans la méthode setContenu() ? Ou alors ce n'est pas du tout comme ça qu'il faut faire ? Voila, pour l'instant, j'ai vraiment l'impression que faire de l'objet en PHP ça se résume à encapsuler des fonctions, mais je ne demande qu'à me tromper. Je vais continuer d'étudier tout ça, je pense que d'ici deux ou trois semaines j'y verrai un peu plus clair.

Bonjour, D'accord, je réalise en effet que sur le long terme, il sera plus efficace d'avoir un code objet, ce sera plus simple à faire évoluer, et plus simple pour le travail en équipe, même si en contrepartie le code est un peu plus lourd. C'est effectivement un bon argument en faveur de l'objet. Dans l'état actuel de mes recherches, il y a principalement deux choses qui me chiffonnent : 1/ Ce qui me pose principalement problème, c'est la durée de vie ultra courte des objets. Imaginons par exemple un catalogue, avec une liste de produits. Au minimum, j'aurai donc une classe Produit et une classe ProduitsCollection. Le client envoie sa requête, sur le serveur j'instancie mes objets, je fais le traitement, tout ça, et j'envoie le rendu html au client. Et après ça : les objets cessent d'exister. Si le client réactualise sa page, ou visualise un autre produit, ou si un autre client demande la même page au même moment dans tous les cas le résulat est le même : sur le serveur je dois tout recommencer à zéro à chaque fois. Alors que dans un logiciel qui serait en java par exemple, les objets, une fois instanciés, existent jusqu'à la fermeture du logiciel. On peut donc réellement les manipuler, les faire interagir entre eux, etc, ce qui est super. Mais là, dans un système client-serveur, c'est un peu comme si on lançait le logiciel des milliers de fois, au moindre affichage de page par un visiteur, voire même à la moindre requête Ajax ! 2/ La deuxième chose, c'est que j'ai l'impression qu'il faut faire tout le travail deux fois : une fois sur les objets proprement dit, et une fois en base de données. Si par exemple le visiteur modifie un objet (exemple : un message de forum), dans mon script, je devrai non seulement mettre à jour mon objet Message, mais je devrai également aller effectuer la modification de ce message dans la base de données. N'est-ce pas étonnant, de devoir tout faire deux fois ? Si quelqu'un pouvait m'éclairer sur ces deux points, je crois que ça m'aiderait beaucoup à avancer, merci d'avance

Merci pour vos avis Effectivement, comme l'ont dit certains d'entre vous, créer une feuille de style spécialement pour les mobiles me semble être un bon compromis, et techniquement très simple (puisque pas de création d'un nouveau template html) et maintenable. Je ne fais jamais semblant

Bonjour, Ces derniers mois, je n'avais pas d'ordinateur chez moi, si bien que j'ai surfé sur le web mobile de façon intensive. Et je suis allée de surprise en surprise, j'ai eu l'impression de revenir en arrière, quand on découvrait le web et qu'on se disait : "waouhh qu'est ce que c'est que cette horreur !" Naturellement, au début, je surfais sur les versions mobiles des sites web, quand elles existent. Et là c'est une catastrophe. Je le dis comme je le pense : je suis à peu près certaine que les développeurs de versions mobiles de sites web, sont des gens qui ne naviguent jamais avec leur mobile. En effet, pour se faire une réelle idée du web mobile, il faut l'utiliser à fond, et pas juste comme ça de temps en temps, or je pense que ces développeurs ne doivent pas souvent quitter leur ordinateur de bureau. La quasi totalité des versions mobiles de sites web sont soit inutilisables, ou du moins, elles sont tellement inférieures aux versions classiques, qu'il est presque nécessaire de switcher sur la version normale. Exemple : site de Météo France. Si je veux savoir quel temps il va faire à Libourne (c'est en Gironde) demain après-midi. Sur la version classique, dès la page d'accueil, je peux entrer le nom de la ville, je clique sur "ok" et sur la page suivante, j'ai le temps qu'il fera demain matin, demain après-midi et demain soir. Maintenant la version mobile : on ne me permet pas d'entrer le nom de la ville, je dois choisir la région. Et là, on me propose une liste réduite de villes, mais pas Libourne. Je clique donc sur une ville proche : Bordeaux. Page suivante : on me donne la liste des jours, et je dois donc cliquer sur "samedi" pour avoir le détail de la journée. Conclusion : trois pages successives, et je n'ai même pas la ville exacte. Et le pire est à venir : si finalement je veux voir les prévisions du dimanche, je dois revenir à la page précédente pour ensuite cliquer sur dimanche (alors que sur la version classique, je pouvais le faire sur la même page). Conclusion : en voulant simplifier la navigation, les développeurs n'ont fait que la rendre très laborieuse. Il s'agit clairement d'un problème d'ergonomie : les développeurs ont oublié que quand on est sur un mobile, chaque changement de page est très long. Il vaut mieux une seule page un peu lourde, que plusieurs pages légères. Prenons un autre type de défaut : un site de banque, par exemple *** (je ne cite pas le nom, écrivez moi en MP pour le connaître). Comme pour la plupart des sites de banque, on me demande d'entrer mon code secret en cliquant sur des numéros dans un petit panneau, pour des raisons de sécurité, ce qui est normal (quoique...). Ici, ce n'est pas une version mobile qu'on me propose, mais une soit-disant "version accessible", dans laquelle je suis sensée pouvoir taper mon code manuellement. Eh bien je n'ai jamais réussi à l'utiliser avec mon téléphone (un Blackberry, testé avec le navigateur blackberry et avec Opera mini), cette version accessible, elle est bourrée de javascrit, ce qui est tout de même un comble pour une version qui se veut accessible ! Un autre exemple que nous connaissons bien : Google. Sur Google mobile, il n'est donné aucune possibilité pour changer la langue des résultats. Par souci de simplification de l'interface, on supprime une fonctionnalité qui me paraît pourtant primordiale. Quant au site de l'opérateur Orange, n'en parlons même pas : la version mobile est tellement différente de la version classique, qu'on a franchement l'impression d'être ailleurs, sur un autre site web sans aucun rapport. Et le pire, c'est qu'ils ne permettent même pas de switcher sur la version classique, ce qui me paraît pourtant être la moindre des choses ! Bref, je ne vais pas énumérer les innombrables déboires des versions mobiles, je pourrais multiplier les exemples à l'infini. Conclusion : j'ai paramétré mon navigateur pour qu'il se fasse passer une bonne fois pour toutes pour un navigateur normal, classique, car c'est la seule façon viable pour utiliser des sites web. Pourquoi je raconte tout ceci ? Eh bien parce que je me pose une question : est-ce que cela vaut la peine, au fond, de développer des versions mobiles de nos sites web. Ca me fait penser à la question souvent posée : faut-il développer une version spéciale pour les non-voyants, ou autres personnes présentant un handicap. Et la réponse des experts est unanime : c'est non. Il faut simplement se débrouiller pour que le site web soit pleinement accessible à tous les visiteurs, y compris ceux présentant un handicap. J'en viens à la même conclusion pour les téléphones : ne vaut-il pas mieux créer un site web qui soit pleinement visitable sur smartphone, plutôt que de faire une version spéciale ? Voici les principaux arguments de ceux qui prônent les versions mobiles : - la connexion des téléphones est lente, on doit donc fournir des pages allégées. - l'écran est petit, il faut s'adapter à cette résolution. - les navigateurs mobiles sont moins performants (notamment celui de Blackberry qui est une horreur, heureusement qu'on peut installer Opera mini sur Blackberry), ou bien ils n'ont pas tous les plugins (pas de flash, excepté sous Androïd), etc... Le navigateur Opera mini résoud les deux premiers problèmes : les pages web sont recréées sur les serveurs d'Opera, qui en fournit une version allégée et réduite au navigateur. Résultat : une navigation super rapide, et un affichage très correct à l'écran. Evidemment, ce système présente aussi ses inconvénients : on est dépendant des serveurs d'Opera, et puis niveau javascript et Ajax, c'est assez moyen car la page est rechargée à la moindre action (ça reste quand même une sacrée prouesse des programmeurs !) Je cite Opera mini, mais mon but n'est pas de faire de la publicité pour ce navigateur, simplement de dire qu'après tout : n'est-ce pas plutôt aux navigateurs de s'adapter ? N'est-ce pas aux navigateurs de se débrouiller pour produire des versions correctes et navigables des sites web, adaptées à de petites résolutions, plutôt qu'aux développeurs de faire des versions light ? Ceci à condition, bien évidemment, que les développeurs proposent un site web accessible et ergonomique, respectant les règles élémentaires dans ce domaine, ce qui n'est malheureusement pas souvent le cas. J'ai exposé mon avis, j'aimerais savoir ce que vous en pensez, merci

D'accord, merci à vous deux pour ces réponses Stéphane, pour te répondre : ce chef était plutôt jeune, moins de 30 ans. Au début il était le seul et unique développeur de la boîte (maintenant on est cinq), et les premiers sites qu'il a faits, c'était en php orienté objet car il avait l'habitude de java. Mais assez rapidement, il a renoncé à l'objet et pris la décision de faire du procédural uniquement, pour les raisons évoquées plus haut. Cela ne l'a pas empêché de monter son propre framework, qui petit à petit s'est enrichi au fur et à mesure des projets et des nouvelles recrues. Bien que non objet, ce framework tenait bien la route, on a quand même créé environ 150 sites web avec, dont certains assez gros et complexes : e-commerce, sites communautaires, etc... C'était du MVC, il y avait des contrôleurs, des librairies de fonctions, des modules réutilisables, des API pour faire de l'ajax, du requêtage sur les BDD, des API pour faire communiquer les sites entre eux, gérer les webservices, etc, bref, un truc tout de même assez complet et performant. Pour l'IDE, on développe sous NetBeans également, et la complétion de fonctions marche bien aussi. Donc voila pourquoi je posais cette question En tous cas je vais continuer d'apprendre à faire de l'objet, ça ne peut être que bénéfique, et puis c'est intéressant (et de toutes façons j'ai pas le choix !)

Bonjour, J'ouvre ce sujet, non pas pour lancer une polémique sur l'utilité de faire de l'objet en PHP, mais pour savoir vraiment quels sont les avantages et les inconvénients (s'il y en a) de faire de l'objet en PHP. Jusqu'à peu, notre chef d'équipe refusait catégoriquement de faire de l'objet en PHP, il disait : "je ne vois pas l'intérêt de faire de l'objet avec un langage procédural, si je veux faire de l'objet je choisirai un langage qui est vraiment fait pour ça, mais certainement pas PHP". Et il ne disait pas cela par ignorance : il était avant tout un spécialiste de Java, donc du pur objet. Dans le même ordre d'idées, il refusait de gérer les relations avec mysql (avec le moteur InnoDB), il disait : "si je veux gérer les relations dans ma base de données, je choisis PostgreSql, qui est vraiment fait pour ça". Mais maintenant on a un nouveau chef d'équipe, qui lui, est dans la philosophie inverse : il veut faire du PHP Objet, et rien d'autre que de l'objet, de façon très poussée. Pour moi c'est assez nouveau, alors ces derniers temps, je m'autoforme à l'objet. Je trouve ça intéressant mais bon, jusqu'à aujourd'hui, très franchement, je ne vois pas ce que ça apporte de plus. Mais je me dis que si tant de monde fait du PHP Objet, c'est qu'il doit bien y avoir des avantages. Alors voila ma question, pour tous les spécialistes : quels sont les avantages de faire de l'objet en PHP ?