[Plan du site] Vous êtes ici --- > Le Site du Zéro > Les news > Tutoriels > Mise à jour du tutoriel PHP > Lecture d'une news

Commentaires de news :
Mise à jour du tutoriel PHP

Revenir à liste des news

Mise à jour du tutoriel PHP

# Par M@teo21, le 19/03/2008 à 10:27:20

Depuis quelques temps, je souhaitais faire plusieurs mises à jour du tutoriel PHP. Rien de bien conséquent soyons clairs, car je n'ai pas le temps de faire une mise à jour en profondeur de ce tutoriel pour le moment.

Toutefois, il m'a semblé nécessaire de faire quelques petits rafraîchissements.

Les chapitres mis à jour

Mise à jour du chapitre sur WAMP pour prendre en compte WAMP 2, la nouvelle version.
Les captures d'écran ont été refaites ainsi que les explications lorsque cela était nécessaire. Heureusement, le principe d'utilisation reste le même donc vous ne devriez pas être trop chamboulés.

Mise à jour de la vidéo "Importer un fichier SQL dans PHPMyAdmin", qui était restée à l'ère EasyPHP.
Le chapitre concerné est "Lire des données" de la section MySQL.

Ajout d'une sous-partie sur l'envoi (upload) de fichiers par formulaire qui m'a toujours semblé manquer.
C'est une sous-partie un peu plus technique que le reste du chapitre mais elle devrait vous permettre de faire vos premiers pas avec l'upload de fichiers.
Toutefois, ce n'est là qu'une brève introduction je ne m'en cache pas, et je n'ai pas cherché à aller plus dans les détails car il existe déjà un excellent tutoriel réalisé par DHKold, dont je me fais l'écho à la fin de ma présentation.

Ce qui reste à faire

Dans la catégorie "Mises à jour à faire", il serait aussi nécessaire de refaire les explications sur le partitionnement sous Linux avec Ubuntu car il a pas mal changé depuis que j'ai rédigé le chapitre.
Toutefois, comme des nouvelles versions d'Ubuntu sortent tous les 6 mois, et que la prochaine devrait arriver en avril (le mois prochain), j'attends la nouvelle version avant de m'en occuper

En C, je mettrai bientôt à jour le chapitre qui présente Code::Blocks au début du cours pour présenter la version stable sortie il y a peu.

Et enfin, puisque je sais que la question va être soulevée dans les commentaires, non je n'ai pas prévu de traiter la POO en PHP pour plusieurs raisons : manque d'intérêt pour la POO en PHP personnellement, peu de courage pour réexpliquer les concepts de la POO en PHP alors que je l'ai fait il y a peu de temps pour le C++, peu de conviction enfin à titre personnel de l'intérêt de telles explications dans mon cours.
Ca ne veut pas dire que c'est définitif, mais il me faudra plus de motivation personnelle pour que je m'y mette. En attendant, ce ne sont pas les tutoriels à rédiger qui manquent !

Retour en haut

185 Commentaires

Désolé, les commentaires de cette news sont désactivés, vous ne pouvez pas en ajouter !

Page : Précédente 1 2 3 4 5 6 7 Suivante

Pseudo

Commentaire

1 visiteur sur cette news (0 membre et 1 anonyme)

Page : Précédente 1 2 3 4 5 6 7 Suivante

Dvassily

# Posté le 21/03/2008 à 19:00:48

Groupe : Membres

Le pire, c'est que j'en était sur de dire une connerie! Mais comme je m'en fout un peu de PHP, j'avais le flemme de chercher...

Utilisateur de Archlinux Gentoo Archlinux<barre></barre>

Mon statut jabber: Image utilisateur

Emacs250

Darth Killer

# Posté le 21/03/2008 à 20:13:08

Dark Burner !

Groupe : Membres

Citation : `Haku

Citation : Darth Killer

Qu'ouïe-je ? Que lis-je ? La poo, inutile en php ? Pour tout code utilisant plusieurs fonctions liées à un même concept, la poo est un outil indispensable pour clarifier le code. Enfin, moi perso, je ne sais plus m'en passer, même en php...

Si tu trouves que l'avantage majeur de l'OO est la lisibilité/clarification du code, c'est que tu ne comprends rien à l'OO (ou que tu codes comme un goret sans OO.

3e option : que la notion même d'objet n'est pas si naturelle pour toi, même si tu l'as comprise et l'utilises.

Je sais pas toi, mais moi je trouve ça plus lisible quand une fonction liée toujours à tel type de fonctionalités sur tel type de paramètre est tournée en méthode d'objet agissant sur cet objet. C'est comme comparer la poo à une chambre rangée, armoire nickelle, etc... à la programmation purement séquentielle qui serait une chambre en cafarnaum complet, tous les outils étant à disposition au sein d'un bOWdel monstrueux. Je vois du moins ça comme ça perso.

Rien de tel qu'une âme perdue comme p'tit dej'...

tonydu76

# Posté le 21/03/2008 à 21:45:30

Le savoir est une arme
Avatar

Groupe : Membres

salut à tous

super cette mise à jour, et pis même si il y a pas se monsieur POO
(que je ne connais même pas en plus)

bon enfin encore merci pour cette mise à jour, et peut-être un jour

une suite comme par exemple "PHP avancer" :-°

tout se sait un jour, il suffit de l'apprendre

Site internet plus d'idée :-°

45577

BouLz

# Posté le 21/03/2008 à 21:52:26

PHP :)

Groupe : Membres

Citation : tonydu76

une suite comme par exemple "PHP avancer" :-°

Ultimate PHP : en période de recrutement :-°

Thibault @ BouLz

LuxSound redémarre :: design en refonte et début du PHP !.

Accessibilité PHP.

anonyme

# Posté le 21/03/2008 à 23:03:57

Groupe :

Citation : Darth Killer

Citation : `Haku

Citation : Darth Killer

Si tu trouves que l'avantage majeur de l'OO est la lisibilité/clarification du code, c'est que tu ne comprends rien à l'OO (ou que tu codes comme un goret sans OO.

3e option : que la notion même d'objet n'est pas si naturelle pour toi, même si tu l'as comprise et l'utilises.

Oh si, un objet est tout ce qu'il y a de plus naturel pour moi. Mais force est de constater que si je ponds un code en procédural et un code en OO qui font la même chose (mais différemment, paradigmes différents oblige), ils sont aussi lisible l'un que l'autre si on sait les lire tous les deux.

Elwish

# Posté le 22/03/2008 à 20:36:34

Telle est la question !
Avatar

Groupe : Membres

Je voudrais constater, une chose, qui va en faire hurler certains, mais ce que je pense.

Le tuto de m@théo es très bien conçu, certes, mais j'ai vraiment du mal à comprendre et assimiler (donc retenir, pour pouvoir l'utiliser

) à partir de MySQL, je trouve que c'est vraiment trop rapide, par rapport à la premièree partie, qui es très bien expliquée, ou le tutoriel C, qui revient, et explique vraiment bien.

Code : PHP

<?php 
if (DC >= 60)
      Smiled ;
else
      Sad; ?>

jarod01

# Posté le 22/03/2008 à 22:34:30

Groupe : Membres

les tutos tombe comme la pluie

Site sur les Sciences =========>>www.sciencesettechniques.com

woufeigh

# Posté le 23/03/2008 à 12:21:40

Webnul

Groupe : Membres

Citation : Elwish

) à partir de MySQL, je trouve que c'est vraiment trop rapide, par rapport à la premièree partie, qui es très bien expliquée, ou le tutoriel C, qui revient, et explique vraiment bien.

C'est ton impression, mais bon ce tuto n'aborde que les bases et si t'as déjà du mal à suivre, je me poserais des questions. Et je ne pense vraiment pas qu'il aille trop vite, et puis tu peut le lire à la vitesse que tu veux...

Haku' un code procédural est moins lisible qu'un code objet. Si on a un mauvais code objet et un bon code procédural c'est sur que c'est le procédural qui sera le plus lisible. Mais à compétence égale dans les deux méthodes le code objet sera toujours plus lisible.

nicknick63

# Posté le 23/03/2008 à 12:27:01

Groupe : Membres

@woufeigh => Ah bon ? Et pourquoi ?
Bon ok pour certains scripts, mais il ne faut pas généraliser, ce n'est pas toujours vrai. Des fois ça se vaut, des fois c'est le procédural le plus visible, des fois c'est l'objet, des fois c'est un autre paradigme...

Envie de discuter avec la communauté d'Exalead ? Allez sur le chat ! (xmpp:exalead@chat.jabberfr.org)
Les tableaux, c'est tabou, on en viendra tous a bout !

anonyme

# Posté le 23/03/2008 à 12:34:35

Groupe :

Citation : woufeigh

Haku' un code procédural est moins lisible qu'un code objet. Si on a un mauvais code objet et un bon code procédural c'est sur que c'est le procédural qui sera le plus lisible. Mais à compétence égale dans les deux méthodes le code objet sera toujours plus lisible.

On appelle ça "un avis" ou "une affirmation gratuite". Donnes donc une preuve.

woufeigh

# Posté le 23/03/2008 à 12:59:49

Webnul

Groupe : Membres

Citation : nicknick63

Avec les classes statiques tout peut être objet.

Citation : `Haku

On appelle ça "un avis" ou "une affirmation gratuite". Donnes donc une preuve.

Prenons l'exemple d'un utilisateur dans un site:

<image>http://www.hiboox.com/lang-fr/image.php?img=3tfdvl2l.jpg</image>

Pour avoir la même chose en procédural, soit tu passes une chiée de paramètres dans tes méthodes soit tu met des global partout. Tant l'un que l'autre alourdissent et rendent donc le code moins lisible.

Après bon un site en objet est plus long à mettre en place from scratch mais pour la manutention c'est plus sympa (quand c'est bien fait bien entendu)

anonyme

# Posté le 23/03/2008 à 13:03:56

Groupe :

J'ai du mal à voir où est ton code plus lisible.. En fait je ne vois même pas de code.
Et puis y a un truc pratique, ça s'appelle "array" je crois.

woufeigh

# Posté le 23/03/2008 à 13:12:42

Webnul

Groupe : Membres

Si tu ne vois pas le concept c'est à toi de te poser des questions et un array n'est jamais qu'une chiée de paramètres avec un seul identifiant, ce qui est encore moins lisible.

Darth Killer

# Posté le 23/03/2008 à 13:30:06

Dark Burner !

Groupe : Membres

Citation : `Haku

Citation : Darth Killer

Citation : `Haku

Citation : Darth Killer

Si tu trouves que l'avantage majeur de l'OO est la lisibilité/clarification du code, c'est que tu ne comprends rien à l'OO (ou que tu codes comme un goret sans OO.

3e option : que la notion même d'objet n'est pas si naturelle pour toi, même si tu l'as comprise et l'utilises.

Un code dit lisible doit l'être même pour quelqu'un qui n'as pas participé à la conception du code en question. quand c'est toi qui conçois, bien sûr que pour toi c'est lisible même si ton code est une foutue poubelle, mais pas nécessairement pour un codeur lambda qui veut ajouter ou modifier dans ton code plus tard... ;p

Note : je n'ai pas dit que tu codes comme une poubelle, j'ai juste parlé du cas possible.

Rien de tel qu'une âme perdue comme p'tit dej'...

anonyme

# Posté le 23/03/2008 à 13:30:49

Groupe :

Je vois très bien le concept, mais c'est toi qui ne comprends pas ma demande.
Tu prétends que le code est plus lisible avec de l'OO, je prétends que c'est faux.
Pour prouver qu'un code est plus lisible qu'un autre, ne faut-il pas montrer les codes à comparer ?

Quand on me dit qu'un marteau est aussi solide qu'un autre, je teste les marteaux et pas le concept du marteau, logique non ?

Et non, un array n'est pas une chiée de paramètre (ou alors, on dira qu'un objet est une chiée de propriétés et de méthodes) mais un conteneur, ce qui est très lisible puisque sémantique (un conteneur regroupant des informations liées).

Citation : Dart-Killer

Ai-je dit qu'il devait avoir participé à la conception ?..
Non, j'ai dit qu'il devait être à-même de le lire correctement. Or pour lire un code correctement, il suffit de comprendre le paradigme qui se cache derrière le code.

Darth Killer

# Posté le 23/03/2008 à 13:33:40

Dark Burner !

Groupe : Membres

Quand on parle de la solidité du marteau, ça concerne le marteau en lui-même. Quand on parle de la lisibilité du code, ça concerne la façon dont il a été organisé, ce qui entre dans la notion de concept.

Ce n'est pas l'array en lui-même qui est peu lisible, mais la tripotée de fonction global avec laquelle tu te retrouves, dès que ton projet grossit.

Lire correctement c'est nécessaire mais pas suffisant pour parler de lisibilité. Et pour la raison que j'ai mentionnée précédemment, un codeur n'ayant pas participé sera plus à même à apprécier la lisibilité (ou son manque) précisément parce qu'il ne pense pas forcément comme le concepteur.

Edit : euh là on va finir par se faire blâmer pour flood dans les commentaires... ^^'
On peut continuer ça par MP si tu veux.

Rien de tel qu'une âme perdue comme p'tit dej'...

anonyme

# Posté le 23/03/2008 à 13:37:49

Groupe :

La façon dont est organisé le code est une propriété du code tout comme la solidité est une propriété du marteau.

Et pour la tripotée de fonction : les namespaces c'est le bien.

woufeigh

# Posté le 23/03/2008 à 14:05:06

Webnul

Groupe : Membres

Ecoute j'ai pas besoin de montrer du code vu que je part du principe simple et évident que plus une fonction a de paramètres moins elle est lisible.

C'est sur qu'un print ne va pas changer de syntaxe d'un code objet à un code procédural...

EDIT: Ok je retire tu as raison Darth Killer

Darth Killer

# Posté le 23/03/2008 à 14:18:12

Dark Burner !

Groupe : Membres

+1 woufeigh pour le principe simple, -1 pour la fin de la 2e phrase... Ya pas de réflexion débile, ya juste une différence de perception d'un même problème.

Rien de tel qu'une âme perdue comme p'tit dej'...

anonyme

# Posté le 23/03/2008 à 14:46:11

Groupe :

Citation : woufeigh

Ecoute j'ai pas besoin de montrer du code vu que je part du principe simple et évident que plus une fonction a de paramètres moins elle est lisible.

Comme tu le dis, "tu pars". Ce qui induit que c'est ton avis, tu n'as donc pas à le poser comme un fait établi et reconnu par tous.
Et franchement, je me demande en quoi le nombre de paramètre d'une fonction a une quelconque influence sur la lisibilité d'un code.

Darth Killer

# Posté le 23/03/2008 à 14:58:55

Dark Burner !

Groupe : Membres

Là t'es bien le premier codeur que je vois dire ça, 'Haku. C'est pas le seul avis de woufeigh, mais celui de la pluspart des codeurs tout langage confondu.

Rien de tel qu'une âme perdue comme p'tit dej'...

DHKold

# Posté le 24/03/2008 à 02:47:24

Ex-Admin

Groupe : Membres

Vos pourriez définir "lisible" ? Un code lisible est-il un code pouvant être compris à la lecture de manière simple?

Si oui, il me semble évident que tout code, toute façon de programmer, peut être lisible.

Après, je vois que le principal avantage avancé pour l'instant dans la lisibilité d'un code OO semble être le regroupement sous forme d'entité de propriétés et de méthodes. Or, la POO, c'est bien plus que ca... Parlons plutôt de la vraie POO, avec l'héritage, le polymorphisme, l'abstraction,...

Dans le cadre d'un projet d'envergure, l'utilisation de la POO permet en général de faciliter la maintenance. Un exemple simple (et courant). Imaginons qu'on traite dans un programme des nombres complexes. En procédural, on en viendrait, au mieux, à stocker un complexe dans un tableau contenant les 2 parties du nombre.

Le problème est alors que le maintient, le stockage et la représentation cohérente de ce nombre dans un tableau est du ressort de l'utilisateur, et la moindre erreur induit une incompatibilité avec les fonctions qui seraient prévues pour traiter les complexes. Biensûr, on peut vérifier la cohérence du nombre en début de fonction, mais on ne peut garantir qu'il est traité de manière cohérente avec sa représentation.

Avec la POO, on créerait une classe Complexe. L'avantage est évident, l'utilisateur n'a plus à se soucier de la cohérence, du maintient ou de la représentation du nombre. Qu'importe si le nombre est stocker sous forme cartésienne, ou sous forme polaire. Et un changement de la représentation n'a pas de répercutions sur l'utilisateur.

Je suis d'accord pour dire que les deux codes peuvent être lisibles, mais je pense qu'on peut facilement affirmer que l'OO est ici plus cohérente comme structure

De là biensur à affirmer qu'un code OO est toujours plus cohérent qu'un code procédural, c'est à priori faux.

Ouverture prochaine
----------
Pack DHemoticons (Utilisation Libre) : Image utilisateur

anonyme

# Posté le 24/03/2008 à 03:20:29

Groupe :

Pourtant, si je regarde ces deux codes :
Code : PHP - Afficher / masquer les numéros de ligne

<?php
class Complex {
private $_real;
private $_i;
public function __construct($real, $i) {
$this->_real = (int)$real;
$this->_i = (int)$i;
}
public function add(Complex $c) {
$this->_real += $c->_real;
$this->_i += $c->_i;
}
public function __toString() {
return (string)$this->_real . ($this->_i >= 0 ? ' + ' : '') . $this->_i . 'i';
}
}
$a = new Complex(2, 3);
$a->add(new Complex(5, 0));
echo $a;
?>

Code : PHP - Afficher / masquer les numéros de ligne

<?php
namespace Complex;
function create($real, $i) {
return array($real, $i);
}
function sum($a, $b) {
return array($a[0]+$b[0], $a[1]+$b[1]);
}
function toString($c) {
return (string)$c[0] . ($c[1] >= 0 ? ' + ' : '') . $c[1] . 'i';
}
// Dans le fichier qui inclu la définition du namespace, on aurait :
require_once './Complex.php';
$a = Complex::create(2, 3);
$a = Complex::sum($a, Complex::create(5, 0));
echo Complex::toString($a);
// On peut aussi utiliser Use pour éviter de nommer explicitement le namespace à chaque appel et utiliser :: si on veut appeler le namespace global( ::fopen(), ..) ou le nom d'un autre namespace si l'on veut utiliser une fonction d'un autre namespace
?>

j'ai l'impression que ni dans l'un ni dans l'autre l'utilisateur n'as besoin de se soucier de la représentation du complexe.
Evidemment, si on avait des structures typées comme les struct du C, le second code serait plus sûr, mais ça c'est une faiblesse de PHP et non du paradigme procédural.
Et par conséquent je pense qu'on peut affirmer que ces deux codes sont aussi cohérents l'un que l'autre.

DHKold

# Posté le 24/03/2008 à 03:58:53

Ex-Admin

Groupe : Membres

Ouai... C'est du procédural, oui, mais qui simule le fonctionnement d'une classe basique (constructeur [pour preuve, tu l'as nommé create], méthodes [bah, une méthode, c'est une fonction qui recoit comme parmètre une structure de données particulière], le tout regroupé au sein d'une même entité, ici sous forme d'un espace de nom).

Bref, ca à l'apparence du procédural, en théorie s'en est, mais au final, ce code utilise des concepts OO...

Je suis d'accord avec toi, tout code procédural peut être aussi cohérent et lisible qu'un code OO...

Ouverture prochaine
----------
Pack DHemoticons (Utilisation Libre) : Image utilisateur

zulon

# Posté le 24/03/2008 à 09:50:26

The shrieker shrieks.

Groupe : Membres

Pas d'accord, le second code a une approche plus fonctionnelle que le premier.
Dans le second, on définit des fonctions qui créent une variable (je ne peux pas dire objet ici, et valeur serait faux, c'est pas du fonctionnel pur) d'un certain type, puis des fonctions qui prennent en argument une/des variables de type complex (en PHP on se soucie pas trop du type, mais bon), et renvoient une variable de type complex, ou bien de type string pour toString.
Si on prend le premier code, l'objet c'est une boîte noire (j'ai horreur de cette métaphore mais elle marche), avec des leviers de commande dessus.
Ça n'a rien à voir: dans le second exemple, les fonctions sont indépendantes des variables, alors que dans le premier, c'est la boîte elle même qui effectue les opérations (ce que je trouve illogique, vu que l'opération d'addition par exemple est totalement commutative).

Et chuis d'accord avec `Haku (je sais jamais où placer le ` :-°

), le nombre de paramètres d'une fonction n'a rien à voir avec sa "lisibilité". Évidemment, en PHP, y'a pas d'application partielle et autres merveilles du paradigme fonctionnel, donc c'est moins pratique, mais bon.
Une fonction peut n'avoir que deux paramètres et être complètement illisible (lignes de 200 chars, code complètement inliné...), et une qui prend sept paramètres l'être beaucoup plus.

woufeigh

# Posté le 24/03/2008 à 11:10:47

Webnul

Groupe : Membres

Citation : DHKold

+1

C'est un peu hypocrite!
De plus tant l'un que l'autre sont illisibles. On commence d'abord par un bonne normalisation des variables, on évite les opérateurs ternaires et puis ta classe est mal imaginée. Surtout quand c'est un exemple qui est sensé démontrer la lisibilité...

Zulon je partait du principe que la personne à un minimum de bases et qu'elle ne va pas coder tout sur une ligne...
Pousser à l'absurde comme ça n'est pas très intéressant pour le débat

Darth Killer

# Posté le 24/03/2008 à 11:39:00

Dark Burner !

Groupe : Membres

Et puis oublions le choix de l'exemple précis de Haku, car c'est pas l'important qu'il ait bien ou mal choisi son exemple.
Imaginons plutôt que ces bouts de codes soient noyés dans un projet plus gros.

Version prodécurale : "aaaaaaah meeerde c'est quelle fonction qui fait ça pour ce truc ? Et elle est où ?"

Version POO : "ce truc est représenté par cet objet, je peux retrouver rapidement la méthode corespondante dans la définition de la classe".

Ya pas photo je crois...

Rien de tel qu'une âme perdue comme p'tit dej'...

bluestorm

# Posté le 24/03/2008 à 11:56:31

dont ask to ask

Groupe : Membres

Tu confonds POO et gestion des namespaces.

C'est pas parce que pendant longtemps le seul moyen d'avoir du code un chouilla modulaire en PHP était de tout foutre dans une classe que c'est la seule méthode qui existe. D'ailleurs, je vois un "namespace Complex" dans le code de Haku`, ça pourraît être un indice ?

Thunderseb

# Posté le 24/03/2008 à 11:59:07

Trolleur en chef !

Je ne sais pas ce qui est pire, un débat Windows/Linux ou Procédural/OrientéObjet. Dans les deux cas, ça ne mène à rien

zulon

# Posté le 24/03/2008 à 11:59:14

The shrieker shrieks.

Groupe : Membres

Si tu vois l'Orienté Objet comme un simple empaquetage de fonctions dans une grosse boîte à outil, c'est que tu n'as rien compris. L'OO ça va bien plus loin que ça, et l'utilisation que tu promeus est celle d'un débutant qui découvre un nouveau paradigme.

woufeigh: Si tu confonds "lisibilité" et "utilisation d'opérateurs ternaires", il y a comme un problème.
Regarde ces deux codes:
Code : C - Afficher / masquer les numéros de ligne

/* Celui-là: */
int abs (int x)
{
return (x >= 0 ? x : -x);
}
/* Et celui ci: */
int abs (int x)
{
int ret = 0;
if (x >= 0) {
ret = x;
} else {
ret = -x;
}
return ret;
}

Selon tes conventions, le second est plus lisible que le premier. Permet moi d'exprimer des doutes... Les opérateurs ternaires ne sont pas une perte de lisibilité. Dans l'exemple de `Haku, leur emploi était totalement justifié.
En passant, je trouve les deux codes tout aussi lisibles. Mais pour moi, lisible ça veut dire qu'on comprend le code sans avoir à réfléchir longtemps, c'est tout.

Edit: bluestorm: salaud :-°