Tutoriel PHP ?

D'où notre vision des choses différentes, comme nous l'évoquions tantôt par MP.

Toi tu vois le PHP comme un langage "mange-CMS" ou "mange-framework" ou simple comme tout, qui permet d'élaborer un site plus ou moins complet mais en peu de temps. C'est bien, car c'est justement à ça que ça sert.

Mais celui qui veut aller plus loin ? Comment il fait ? Car au final, cela revient à faire un tuto "crée ton site avec PHP" qui va au final s'arrêter où ? Traiter quelle partie ? Qu'est-ce que ton tuto apportera de plus qu'un autre ? C'est pour cela que je pense que le fait de dispatcher les connaissances peut être vu un peu, par un débutant : "ooooh… La temporisation de sortie ? Boarf, c'est pas important, j'ai déjà lu tout le tuto sur PHP". Enfin c'est un exemple comme un autre, hein.

Après, c'est deux visions différentes : il y a "la pratique" et "les bonnes pratiques"… Mais après faut pas s'étonner des codes bordéliques. Et surtout, saura-t-il lire la doc ?

EDIT : je suis assez critique vis à vis de MVC, je te prie de m'en excuser, je m'emporte un peu quand j'en parle.

Je suis d'accord pour le côté bonnes pratiques, le problème c'est que s'il faut tout traiter dans un seul tutoriel ça va surtout faire fuir tout le monde plutôt que d'attirer les débutants qui veulent simplement mettre en place leur petit site.

S'ils veulent vraiment aller plus loin, il faudra dans tous les cas passer par la case formation avancée, via des tutos plus ciblés par exemple. Et s'ils veulent vraiment un truc plus avancé que du simple PHP de base, il y a des chances pour qu'ils doivent se tourner vers des technos plus adaptées…

Effectivement, je ne pense vraiment pas que créer un cours sur le PHP détaillant toutes les possibilités de la POO soit une bonne idée. Par contre, si on veut expliquer au lecteur comment se servir de PDO par exemple, il me semble nécessaire de parler de POO avant. Bien entendu, il est inutile de parler de POO avancée ; à la limite, parler juste de POO côté client serait utile (notion de classe, d'objet, d'instance, de constantes de classe, d'héritage et d'exceptions, en s'appuyant sur PDO pour le fil conducteur).

viki53 > même pour des sites basiques, le pattern MVC est une très bonne façon de procéder, j'avoue ne pas vraiment comprendre à quoi tu peux faire référence.

En effet, détailler toutes les subtilités de PHP dans le tuto est à mon avis inutile, pas parce qu'ils sont débutants, parce qu'ils doivent apprendre à lire la doc., on ne doit pas leur mâcher le travail. Je pense que savoir lire la doc., "se démerder tout seul", disons, c'est pas important uniquement en PHP, mais dans n'importe quel langage.

EDIT : Donc parler de POO, oui, de MVC, pourquoi pas, mais n'évoquer vraiment que la base de la base.

Le but c'est de faire un tuto accessible pour les débutants, pas un fourre-tout pour maîtriser 100% du langage. Les points particuliers comme ça ont plus leur place dans des tutos spécifiques qui permettent de voir ça en profondeur. Sinon on va finir avec un tuto énorme qui va faire peur aux lecteurs dès la vue du plan…

A mieux articuler son code ? A centraliser les éléments redondants ? A améliorer la maintenance du site ? A aider aux stratégies anti-piratage ? Franchement, la liste de ce que même un débutant peut en tirer est tellement longue que j'y serais encore demain.

Par contre, je suis d'accord, peut-être que tous les patterns ne sont pas utiles pour un débutant, donc un catalogue de patterns ne serait peut-être pas adapté. En revanche présenter juste quelques patterns avec leurs applications concrètes peut être très intéressants. Pour un débutant, me paraissent assez incontournable la plupart des patterns créationnels : Singleton, Factory Method, Abstract Factory. Aussi très important, State et Strategy. Juste avec ces 5 là on a beaucoup à en dire…

Pas vraiment. C'est là qu'on fait la grande différence entre une application (site web ou non) faite à l'arrache et une faite proprement. L'intérêt du développement en couche (dont le MVC n'est qu'un aspect et une partie de l'application) c'est justement de bien délimiter le rôle de chaque pièce pour que par la suite la maintenance en soit facilitée. Ce n'est pas juste pour les fichiers : ce n'est pas juste le fait que seule la vue doit envoyer du code HTML, il y a aussi que seul le contrôleur doit pouvoir piloter l'application dans son ensemble.

D'ailleurs sur un dev en couche plus complet, M + V + C == IHM, la couche de présentation, et tu as d'autre couches à côté : BLL pour la logique de l'application, BO pour les entités, et DAL pour l'accès aux données (base de données, mais pas seulement). En Java EE, c'est nativement implémentée sous la forme de servelts et pages JSP, en PHP il faut le faire nous-même. Soit.

C'est vrai qu'on ne voit pas assez d'explications sur comment lire la doc dans les tutos, ni accentuer sur l'importance de fouiller celle-ci de manière systématique. Les 4/5 des demandes d'aides que j'ai pu rencontrer depuis longtemps sur le forum PHP du SdZ et d'OCR étaient des cas typiques de doc mal lues ou non-parcourues.

Edit : Et en définitive, je crois que je vais changer ma grosse série de tuto parce que c'en devient déraisonnable. Je vais me limiter à la partie analyse pour l'heure. Par conséquent, je suis dispo comme contributeur ou co-auteur si vous avez besoin de moi en PHP, que ce soit sur des points particuliers ou pour une vue générale.

en PHP il faut le faire nous-même. Soit.

comme en Java, soit tu le fais toi même soit tu utilises un framework.

C'est vrai qu'on ne voit pas assez d'explications sur comment lire la doc dans les tutos, ni accentuer sur l'importance de fouiller celle-ci de manière systématique. Les 4/5 des demandes d'aides que j'ai pu rencontrer depuis longtemps sur le forum PHP du SdZ et d'OCR étaient des cas typiques de doc mal lues ou non-parcourues.

sur OC tu as deux types de questions :

• comment faire XXX avec Symfony
• PDO marche pas

A partir de là, je sais pas ce qu'on peut tirer mais bon.

Bah pas exactement, le fait que les servlets que tu fais toi-même ne doivent envoyer aucun code HTML au client, mais plutôt le déléguer aux pages JSP (même si ces dernières sont compilées en servlets), permet d'organiser pas mal son IHM suivant le modèle MVC. On se doit de faire ça propre soi-même, certes, mais le langage est au départ prévu pour ça dans ces specs. PHP n'a rien de tel, et c'est ce que j'essayais de souligner.

Tu oublis : "j'ai une page blanche", "mail() ne marche pas", "ma requête n'affiche rien et ne fait rien" (typiquement pas de gestion des erreurs d'activée), et autres joyeusetés très courrantes.

Honnêtement ça sert à quoi pour un débutant qui veut juste faire un petit site vitrine ou bidouiller un WordPress de connaître les design patterns ?

Le but c'est de faire un tuto accessible pour les débutants, pas un fourre-tout pour maîtriser 100% du langage. Les points particuliers comme ça ont plus leur place dans des tutos spécifiques qui permettent de voir ça en profondeur. Sinon on va finir avec un tuto énorme qui va faire peur aux lecteurs dès la vue du plan…

A mieux articuler son code ? A centraliser les éléments redondants ? A améliorer la maintenance du site ? A aider aux stratégies anti-piratage ? Franchement, la liste de ce que même un débutant peut en tirer est tellement longue que j'y serais encore demain.

Par contre, je suis d'accord, peut-être que tous les patterns ne sont pas utiles pour un débutant, donc un catalogue de patterns ne serait peut-être pas adapté. En revanche présenter juste quelques patterns avec leurs applications concrètes peut être très intéressants. Pour un débutant, me paraissent assez incontournable la plupart des patterns créationnels : Singleton, Factory Method, Abstract Factory. Aussi très important, State et Strategy. Juste avec ces 5 là on a beaucoup à en dire…

Sauf que justement tu parles d'applications. Le but ici est d'apprendre à créer un site, pas une application qui va demander des connaissances plus pointues. Tu as un tuto orienté vers ce domaine, c'est déjà suffisant.

Les débutants en ont strictement rien à faire des designs patterns (moi-même je serais incapable d'expliquer le principe alors que je fais du PHP depuis plus de 6 ans) pour leur petit site vitrine ou leur blog maison.

Pour être parfait il faudrait traiter tous les sujets, mais ce serait aussi effrayer les débutants qui veulent juste un truc simple et qui fonctionne : la sécurité et autres c'est pas leur objectif premier. Il faut savoir partir de ce que le lecteur veut, pas de ce que vous voulez si vous voulez que le tuto soit vraiment utile. Une fois que le lecteur aura ce qu'il veut vous pourrez le mener autre part…

Les questions que vous citez sont révélatrices : les débutants commencent d'abord par les choses simples pour savoir comment ça fonctionne. Une fois qu'ils ont assimilés les bases, ils vont voir ailleurs (MVC, POO avancée, design patterns et whatnot…)

Parce qu'un site web n'est pas une application ? J'en apprends tous les jours… Ce n'est pas une application CLIENT LOURD, ok, mais c'est une application quand même.

Tu peux toujours t'en passer tout comme tu peux te passer de la POO en entier. Tu vas juste devoir résoudre toi-même des problèmes qui ont déjà été résolus et optimisés pour toi par des pros depuis quelques décénies déjà…

Je suis d'accord sur le fait qu'un tutoriel traitant de tout serait au final plus effrayant d'autre chose. Peut-être qu'un tel cours est à réserver au support papier…

Tu m'as très bien compris. On peut aussi que c'est un logiciel, ça ne changera rien au fait qu'un simple site Web ne nécessite pas de sortir la grosse artillerie, encore moins pour un débutant.

Support papier ou non, plus c'est long, plus ça fait peur et moins ça donne envie de s'y mettre. Il vaut mieux y aller étape par étape que d'un seul coup.

Et ça marche pour quasiment n'importe quoi : donne-moi un petit livre à lire c'est fait presque aussitôt, demande-moi de lire un truc de la taille d'un dico j'aurai même pas envie de lire le résumé…

C'est une simple question de pédagogie, rien à voir avec quelle techno est la meilleure ou qui a la plus grosse. Si vous voulez vraiment faire de la pub pour une techno particulière, faites-le dans un tuto dédié, pas dans celui qui s'adresse aux débutants (qui plus est ceux qui seront incapables de faire un choix en toute connaissance de cause et suivront donc aveuglément vos conseils sans y réfléchir à deux fois comme ceux qui s'attaquent à Symfony avant même de savoir faire un var_dump que l'on voit sur OCR).

à mon avis, c'est une erreur de ce limiter aux bases, parce que soit à la fin du tuto (de base):

• les lecteurs se diront "ayé, je sait coder en php, je suis un cador, envoyer moi un badge..ou un mooc....:°"
• les lecteurs partirons ailleurs, faute d'avoir eu l'info sur le super tuto qu'ils suivaient (du coup, ben doute du genre "finalement, il étais pas gégé ce tuto ! il connais même pas X processus ou fonction ou…")

de mon ressenti, en tant que lecteur, et apprenti, j'aime pas resté dans le flou, ressentir l'impression qu'on m'a pas tout dit… limite "chui trop c*n alors j'y est pas droit ??" "

à mon avis, un tuto qui apprend les bases n'est en fait qu'une partie d'un tuto qui fait le tour de tout, point par point.

que le tuto soit long ne me parait pas un problème en soit: le lecteur est là pour apprendre un langage (pas une recette de cuisine), il sait (ou se doute fortement) que cela ne s'apprend pas en 3 jours. En fait, ce qui fait une grosse différence entre un tuto super-lourd indigeste et un tuto qui sera suivi réside d'une part dans l'implication du lecteur (fil rouge blog, ça c'est ok ) et dans le découpage du tuto, avec des étapes clefs. chaque étape doit, pour le lecteur, être motivant par le fait qu'elle lui apprend quelque chose de spécifique "quand j'aurais lu ce chapitre, je saurais faire cela !" c'est très stimulant pour lui (surtout si c'est rattaché à son objectif ) de plus, ça permet aussi de recevoir des lecteurs ayant déjà quelques connaissances apprise ailleurs, mais n'ayant pas reçu tel ou tel info dans leurs formations…bref, (ce n'est que mon avis)mieux vaut un super-tuto-méga-long-mais-très-bien-découpé, qu'un énième tuto qui t'apprend-les-bases-à-la-va-comme-j'te-pousse de plus sur la toile.

C'est pas plus complexe d'expliquer le pattern MVC que du code serveur qui crache de l'HTML directement à un débutant. Je ne suis absolument pas d'accord avec ça.

J'ai commencé le développement web en utilisant Ruby on Rails (avant même de toucher à PHP) ça ne m'a pas du tout semblé insurmontable.

J'ai pas envie de me lancer dans le débat du "est-ce-qu'il vaut mieux apprendre le MVC ou pas en PHP", mais en tout cas, de brut en blanc, je ne trouve pas que ce soit beaucoup plus complexe pour le mec qui n'a aucun a priori. Ca vous semble juste plus naturel parce que c'est la démarche que vous avez suivie.

Dans 90% des cas, le mec qui passe du développement d'une page statique à un site dynamique, ça ne va pas pour mettre un petit snippet dans sa page html, mais bien pour stocker des données ou un état.

Lui expliquer que le contrôleur intercepte sa requête puis la traite, avant d'envoyer les données à une vue (la partie qu'il connaît déjà) c'est juste lui expliquer qu'il connaît 1 brique sur trois. C'est pas très complexe au final.

Le problème c'est que le tuto a pour but d'enseigner les bases, pas le langage en entier. Donc parler d'autant de choses, bien souvent sans intérêt pour un débutant, ne ferait que le perdre.

Autant dire (et répéter) que le tuto ne couvre que les bases et proposer des pistes pour aller plus loin ensuite… Ce ne sera que plus gratifiant pour le lecteur qui se dira "OK, j'ai compris la base, maintenant je peux aller voir plus loin pour créer un vrai système complexe".

Et c'est vrai pour tous les langages : on ne commence pa avec Java en créant toute une interface graphique mais avec des simples algos contrôlés via la console. Idem en C…

Quelque chose qui ne vous paraît pas très complexe parce que vous avez l'habitude du développement pour paraître extrêmement compliqué à un débutant qui a déjà du mal à mettre en forme sa page avec du CSS.

Pour éviter de le perdre tout en abordant pas mal de problématique, utiliser un fil rouge peut être intéressant. Du reste moi je dis juste que si je suis d'accord avec le fait qu'un tel tuto ne couvre que les bases en invitant le lecteur à approfondir ailleurs, je trouve simplement que ta perception de ce qui fait partie des bases est plus que restrictive…

Je suis bien conscient que c'est restraint. Mais si on ne restraint pas on va vite finir par évoquer tous les aspects du langage, y compris les plus tordus.

Il faut commencer par poser des limites et voir ce qui est réellement utile pour un débutant. Même si certains aspects de sécurité ou d'organisation sont importants pour nous et pour d'autres, ce n'est pas ce qui intéresse les débutants.

Le but est d'avoir un tuto qui soit lu, pas une bible posée dans un coin pour ceux qui ont le courage de la parcourir…

Il faut restreindre, oui, mais pas ignorer des domaines entiers. Certains domaines sont à faire en profondeur, d'autres à évoquer, et d'autres un "entre-les-2".

J'ai l'impression qu'on se dirige vers un très gros tuto et pour moi c'est une mauvaise idée. En effet, rien de plus rebutant qu'un cours trop énorme pour qu'on en perde la vision d'ensemble ? Je serais plutôt pour adopter un principe fondamental en informatique, à savoir : les modules, et à l'appliquer à un ensemble de cours sur le PHP. Il y aurait un cours fondamental, le "core", qui regrouperait les notions de base. Ensuite, on redirigerait vers chaque cours non pas dans un ordre prédéfini, mais en fonction de problématiques (il faut pas oublier que la personne qui cherche à apprendre un langage, veut surtout résoudre un problème !). Par exemple,

• Comment stocker mes données ? Tutoriel sur les moyens de stockages (BDD, etc)
• Comment mieux réutiliser mon code ? Tutoriel sur la POO

L'avantage de faire comme ça est de pouvoir proposer des mini-projets très concrets. Chaque tuto pouvant évidemment dépendre d'autre(s) (tout comme les dépendances entre modules !).

Qu'en pensez-vous ?

PS : Je fais du Drupal en ce moment donc je parle beaucoup de modules Mais je crois vraiment en un format de tuto de ce genre.

perso, je persiste à penser que faire un tuto "de base" (comme on en vois déjà un peu partout) n'apportera rien (ou pas grand chose) au lecteurs, en revanche, des tutos super-complet, ça court pas les rues !

Comme je l'ai déjà dit, tout se joue dans le découpage et l'aspect "participatif" (limiter la théorie, privilégier la pratique, et de préférence, centrer la pratique sur un cas générale qui intéresse le plus de lecteur=>blog)

Evidemment, ce n'est que mon point de vue, mais je me vois mal m'engager dans cette aventure si la trame final de ce tuto s'éloigne trop de ma conviction (évidemment, je suis pas indispensable non plus )

J'ajoute ma pierre à l'édifice. J'ai vite fait parcouru le sujet, mais voilà mes 2 cents…

Autant OK pour avoir un tuto général qui explique les bases (en laissant celui d'`Haku approfondir), et qui aborde vite fait (mais de manière concise, et sans laisser de places aux anneries) l'OO. Mais avoir tout pêle-mêle, ça je suis pas convaincu que ce soit la bonne démarche.

Par contre, essayer de séparer un peu les concerns (un tuto intro, un tuto plus approfondi sur le procédural (je pense au tuto d'`Haku), un tuto plus approfondi sur l'objet (l'ancien tutoriel de vyk12 ? Je sais pas s'il compte passer par ici), et pourquoi pas à termes avoir des tutos sur le MVC ou bien Sf2), ça serait je pense plus abordable ?

vyk12 est déjà passé par ici Talus . Pour ce qui est du cours sur symfony il y a déjà ça non ? http://zestedesavoir.com/tutoriels/324/developpez-votre-site-web-avec-le-framework-symfony2/

Talus > Je ne vois pas ce que tu veux dire par « un tuto intro, un tuto plus approfondi sur le procédural (je pense au tuto de Haku) ». De ce que j'ai pu voir, le tuto de Haku propose déjà les bases, donc je ne comprends pas ce que tu voudrais mettre dans le tuto intro (à moins que tu comptais « scinder » le tuto de Haku ?)