Commentaires de malalam sur tout CodeS-SourceS

1652 commentaire(s) de malalam sur des sources sur tout CodeS-SourceS

Le : 14/05/2008 22:52:24
Source : [PHP 5.1] CLASS STRING : NOUVEL EXEMPLE SUR LA SPL

Hi,

c'est très exactement la même base que la classe de Neige. Sauf que l'idée n'est pas la même; le but, si : montrer la SPL en action. L'idée, non...moi, j'avais envie de m'amuser à utiliser les fonctions de tableau de PHP (puissantes et pratiques) sur des chaînes. Ca c'est l'excuse :-) Le truc que je voulais vraiment montrer, c'est d'une part la SPL (là, c'est exactement comme la classe de Neige), et une utilisation possible de la méthode __call(). On voit la même utilisation dans certains exemples de la SPL PHP (CacheIterator par exemple).
Ce n'est pas parfait, c'est juste un exemple, c'est purement didactique. Mais je pense qu'en fouillant on peut arriver à un truc extrêmement puissant. Là ça marche déjà pas mal mais c'est du bricolage (la constante à passer pour faire un retour par référence, etc...).
Bref l'idée est juste de montrer encore une fois qu'on peut s'amuser avec la SPL... :-)

Le : 14/05/2008 07:59:19
Source : [PHP 5.1] CLASS STRING : NOUVEL EXEMPLE SUR LA SPL

@depression : oui...encore que, je suis persuadé que c'est pas le cas pour tout le monde...et tu l'apprends comment ? Par exemple, parce tu auras vu un commentaire du type "On incrémente notre variable : $a++;" (ou ++$a). Que ce soit dans un bouquin, la doc, un cours, un tuto, un code, et quelle que soit la forme.
Mon point de vue est qu'il n'y a jamais trop de commentaires. D'ailleurs sur ce code j'ai pas terminé, je rajouterai les suivants plus tard. les commentaires aident à suivre le cours du code.

@coucou : voui, de toute manière cette classe n'a pas pour vocation d'être une classe complète de typage. Même si le sujet est intéressant et que je ferai peut-être évoluer le bin's dans ce sens un jour. Et ça peut-être amusant de compléter celle-là voir jusqu'où on peut aller, en effet :-)

Le : 13/05/2008 22:49:31
Source : [PHP 5.1] CLASS STRING : NOUVEL EXEMPLE SUR LA SPL

Hello,

ça s'appelle de l'emphase : j'insiste simplement sur le fait que OUI, c'est une chaîne (enfin, ça y ressemble), que OUI c'est une méthode, que NON elle n'est pas définie dans ma classe, mais que OUI je vais bien l'utiliser, cette méthode non définie, qui trie un tableau, et ce sur une chaîne.
Et ton exemple est pourtant plus utile que mon commentaire, parce que, encire faut-il savoir que ++ est un opérateur d'incrément...après tout, à qui servent les commentaires ? A ceux qui comprennent tout de suite? Naan...

Le : 06/05/2008 23:15:36
Source : EXTRACTEUR DE VARIABLES DE FORMULAIRES

Si tant est que le HTMl soit un bon XHTML, sinon il faut d'abord parser et c'est chiant (je sais, je l'ai fait souvent lol). Mais en effet, j'y avais pensé en voyant ce code.

Le : 06/05/2008 22:25:50
Source : EXTRACTEUR DE VARIABLES DE FORMULAIRES

Hello,

je comprends le point de vue "entreprise"; ceci dit, là, on est sur un site "open source". Et je suis d'accord avec Coucou et FhX : quand on poste un code open source, on fait propre. Je ne pense pas que là-dessus, tu aies raison de rebiffer. Et vu la longueur du code, ça ne te prendrait pas des heures de le réécrire proprement, voire de réfléchir à une autre manière de le faire.

Par contre, contrairement à Coucou, je trouve ta dernière phrase très intéressante et je vais y répondre :
oui, je cracherais dessus...parce rouler dans une 2 chevaux qui aurait un moteur de porsche, ce serait le meilleur moyen de se tuer à coup sûr...il en va exactement de même avec les codes... : un code mal écrit mais très utile...est généralement un code très dangereux.

Je ne pense effectivement pas que FhX aie réellement compris à quoi servait ton code. Je ne lui jette pas la pierre, j'ai eu du mal aussi; et FhX est un excellent codeur PHP, ses conseils sont tjrs avisés (comme bcp ici hein, Coucou, Neige, Yoman, je ne sais plus qui a posté donc désolé pour les autres que jh'ai oublié :-) ).
Ton code présente quand même bcp de lacunes pour être vraiment utiles au plus grand nombre... : la syntaxe de la création de la table ne conviendra pas à toutes les BDD; la table est extrèmement basique à tous les points de vue : impossible d'exploser les champs d'un formulaire sur plusieurs tables, impossible de jouer avec des tables de jointure (un select, typiquement...ça demande svt une table de jointure), impossible de changer les types (une table avec tous les champs en 'text'...boaf...), impossible de créer des clefs étrangères etc. Bref, il n'y a pas que le code en lui-même qui n'est pas optimisé : son résultat ne le sera pas non plus. Ce code crée des tables qui seront très lentes et dont la structure sera très mauvaise, quasiment à tous les coups.
Je suis d'accord : on se fout, dans un tel cas, que le code prenne des heures à s'exécuter ou quelques minutes...mais le résultat, lui, doit être optimisé, sinon quel intérêt ? Se retrouver avec un site très mal structuré et lent ? Je préfère encore passer du temps à me taper à la main le MCD et avoir une vraie structuren, plutôt que de lancer ce code et devoir tout modifier, ce qui sera sans doute plus long.
Et j'aimerais bien avoir ton point de vue là-dessus en tant que salarié d'une entreprise : parce que si l'entreprise n'aime pas que l'on passe trop de temps à développer un truc...elle aime encore moins que le truc développé soit lent, mal optimisé, et ne satisfasse du coup pas les clients.

Le : 04/05/2008 17:24:57
Source : RECHERCHE DES VILLES ET CODES POSTAUX FRANÇAIS

Hello,
c'est ça que n'aiment pas tes hébergeurs parce qu'ils sont en short_tags à On.
<?xml version="1.0" encoding="UTF-8"?>
Vire cette déclaration, elle n'est pas indispensable.

Le : 01/05/2008 14:51:19
Source : INCLUDE "SECURISÉ" VIA FICHIER INI FACILEMENT EDITABLE

Ne prenez pas l'exemple de sites fonctionnant par inclusions, mais de sites classiques basés juste sur des pages. Je ne vois pas en quoi cela change quelque chose que l'on voit ou non machin.php plutôt que main.php?page=1.
Si le site est mal codé, dans les 2 cas, les problèmes sont les mêmes. Ca n'est pas moins sécurisé de voir le nom des fichiers php utilisés.
Parce que être parano, c'est bien...mais il faut l'être à bon escient : vous ne serez pas plus capable de sécuriser dans un cas que dans l'autre. Et si vous faîtes face à un piratin ayant un meilleur niveau que vous, dans les deux cas, il trouvera la faille. On ne sécurise pas un site pour les utilisateurs lambda, parce qu'eux ne représentent pas une menace : ils ne savent pas comment exploiter une faille.
Un bon piratin le sait, lui...et si vous n'avez pas un bon niveau, dans les deux cas, vous êtes morts.
Et si vous avez un bon niveau...que votre site affiche ou non en clair dans l'url les fichiers php qu'il utilise, ça ne changera rien, c'est le piratin qui est mort.
Bref, un bon piratin verra la lumière dans l'obscurité, croyez-moi...penser que simplement masquer le nom des fichiers utilisé est une sécurité est illusoire dans ce cas.
Il faut bien plus s'intéresser aux injections et autres XSS...et les XSS se basent souvent sur...des POST ou des GET...en se contrefichant éperduement du nom des fichiers que VOUS vous incluez, de manière masquée ou non. Parce que ce ne sont pas VOS scripts qui l'intéressent dans ce cas, mais les siens...à priori, les vôtres ne peuvent pas faire de mal à votre site ;-)

Le : 01/05/2008 13:17:42
Source : INCLUDE "SECURISÉ" VIA FICHIER INI FACILEMENT EDITABLE

Encore faut-il parvenir à accéder au serveur de manière à connaître les noms des fichiers pour pouvoir récupérer le .ini.
Et de toute manière, c'est de la sécurisation de base; et c'est valable pour beaucoup d'autres choses : xml par exemple.
Ensuite, j'aimerais savoir en quoi cela peut poser problème qu'un utilisateur connaisse les fichiers inclus dans un site ? Non parce que pour ça, il suffit de surfer sur le site hein...et on les connait tous, les .php utilisés...et ?

Le : 01/05/2008 11:58:18
Source : INCLUDE "SECURISÉ" VIA FICHIER INI FACILEMENT EDITABLE

Heu ça fait 2 fois : je pourrais savoir en quoi la liste est lisible...?

Le : 01/05/2008 10:40:35
Source : INCLUDE "SECURISÉ" VIA FICHIER INI FACILEMENT EDITABLE

Hello,

je trouve aussi l'intention louable. Ceci dit, passer par parse_ini_file() pour ça me semble un peu compliqué. Mais pourquoi pas.

@pysco68 => require_once("chemin/vers/mon/fichier/include") or die("Le fichier untel n'a pas pu être chargé!");
ton or die() ne sert à rien. require génère une erreur fatale si le fichier demandé n'existe pas, et ne renvoie jamais false. Ton die() ne sera jamais exécuté. Ce genre de solution n'est de toute manière pas satisfaisante : on n'essaye pas d'éviter une erreur, on fonce dedans en se disant que si une erreur survient, on quitte le script. Il vaut toujours bien mieux vérifier qu'on n'aura pas d'erreur, plutôt.
Et je ne comprends pas ta phrase qui suit ce bout de code, au passage.