Vous vous souvenez quand le register_global faisait des siennes. Pour un
grand nombre de developpeurs il a fallu reprendre le code notamment pour les
formulaire et changer:
$toto (issu du champs de formulaire ... name="toto">)
en
$_POST['toto'].
Pour ma part, je me suis dit qu'il etait hors de question de reprendre des
pages et des pages de codes faites par des predecesseurs ou moi meme.
J'ai donc cree ca:
if(isset($_POST)) {
foreach($_POST as $key=>$val) {
//echo $key.'=>'.$val.'<p>';
$$key = $val;
}
}
Que je mettais en haut de toutes mes pages. Et ca donctionne tres bien.
Puis je me suis dit que je pouvais faire la meme chose pour une requete
SELECT. Imaginons qu'une table contienne 70 champs et que vous souhaitez
tout afficher (les 70 champs).
J'ai donc fait ceci:
$requete = "SELECT * FROM gest_parc";
$resultat = mysql_query($requete);
Ce qui m'evite de faire:
while ($row=mysql_fetch_object($resultat)){
$id = $row->id;
$nom = $row->nom;
.
.
.
.
}
ou un fetch_array ou encoe un mysql_result...
Tout ceci fonctionne a merveille. MAintenant la question que je me pose
c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les
applis qu'on trouve en open-source.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a
l'encontre de l'efficacite ou d'un certain "bon procede".
Ouais. Bien. Bravo. <imaginons> Je viens d'hériter de ton projet, et je suis vachement content de devoir consulter le schéma de la base et les valeurs possibles de $_GET et $_POST (que tu a traité de la même façon) pour savoir qui est qui, qui vient d'où, et pourquoi tout ça bugge de partout depuis la modif dernière modif qui semblait pourtant bien innocente à première vue...
Vraiment vachement content. </imaginons>
Ce qui m'evite de faire: while ($row=mysql_fetch_object($resultat)){ $id = $row->id; $nom = $row->nom; }
Quel est le problème avec $row->id (ou $row['id'], etc) ? Tu a déjà tes valeurs disponibles et accessibles avec un identifiant clair et lisible, *explicite*, et cantonné à un espace de nommage bien délimité ce qui évite bien des effets de bords intempestifs.
Autant je comprenais la raison d'être du $$hack sur $_POST ou $_GET ou etc pour éviter de corriger des centaines de lignes de code (qui auraient gagnées à être écrites plus proprement dès le début, mais bon, c'est un autre débat), autant là, à part gaspiller des ressources et rendre le code ch... la mort à maintenir, je ne vois vraiment pas l'intérêt de la manoeuvre.
Mes deux centimes... -- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Alexandre wrote:
(snip)
foreach($row as $key=>$val) {
$$key = $val;
}
}
Ouais. Bien. Bravo.
<imaginons>
Je viens d'hériter de ton projet, et je suis vachement content de devoir
consulter le schéma de la base et les valeurs possibles de $_GET et
$_POST (que tu a traité de la même façon) pour savoir qui est qui, qui
vient d'où, et pourquoi tout ça bugge de partout depuis la modif
dernière modif qui semblait pourtant bien innocente à première vue...
Vraiment vachement content.
</imaginons>
Ce qui m'evite de faire:
while ($row=mysql_fetch_object($resultat)){
$id = $row->id;
$nom = $row->nom;
}
Quel est le problème avec $row->id (ou $row['id'], etc) ? Tu a déjà tes
valeurs disponibles et accessibles avec un identifiant clair et lisible,
*explicite*, et cantonné à un espace de nommage bien délimité ce qui
évite bien des effets de bords intempestifs.
Autant je comprenais la raison d'être du $$hack sur $_POST ou $_GET ou
etc pour éviter de corriger des centaines de lignes de code (qui
auraient gagnées à être écrites plus proprement dès le début, mais bon,
c'est un autre débat), autant là, à part gaspiller des ressources et
rendre le code ch... la mort à maintenir, je ne vois vraiment pas
l'intérêt de la manoeuvre.
Mes deux centimes...
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Ouais. Bien. Bravo. <imaginons> Je viens d'hériter de ton projet, et je suis vachement content de devoir consulter le schéma de la base et les valeurs possibles de $_GET et $_POST (que tu a traité de la même façon) pour savoir qui est qui, qui vient d'où, et pourquoi tout ça bugge de partout depuis la modif dernière modif qui semblait pourtant bien innocente à première vue...
Vraiment vachement content. </imaginons>
Ce qui m'evite de faire: while ($row=mysql_fetch_object($resultat)){ $id = $row->id; $nom = $row->nom; }
Quel est le problème avec $row->id (ou $row['id'], etc) ? Tu a déjà tes valeurs disponibles et accessibles avec un identifiant clair et lisible, *explicite*, et cantonné à un espace de nommage bien délimité ce qui évite bien des effets de bords intempestifs.
Autant je comprenais la raison d'être du $$hack sur $_POST ou $_GET ou etc pour éviter de corriger des centaines de lignes de code (qui auraient gagnées à être écrites plus proprement dès le début, mais bon, c'est un autre débat), autant là, à part gaspiller des ressources et rendre le code ch... la mort à maintenir, je ne vois vraiment pas l'intérêt de la manoeuvre.
Mes deux centimes... -- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Patrick Mevzek
Pour ma part, je me suis dit qu'il etait hors de question de reprendre des pages et des pages de codes faites par des predecesseurs ou moi meme. J'ai donc cree ca: if(isset($_POST)) { foreach($_POST as $key=>$val) { //echo $key.'=>'.$val.'<p>'; $$key = $val; } }
Vous faites la même chose que register_global, vous serez donc vulnérables aux mêmes problèmes.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Il n'est pas bon de polluer un espace global de variables limité, et personnellement je ferais et encouragerais toujours les gens à faire l'exact contraire de ce que vous faites.
Quand vous avez $age dans votre code, impossible de savoir si cela vient du formulaire ou en interne de votre application, il faut vous farcir toutes les lignes qui précèdent. Si vous avez $_POST/$_GET/$_REQUEST['age'] vous savez sans ambiguités de quoi vous parlez.
Pour les informations tirées de la base de données, elles devraient de toute façon être de portée réduite, car les accès au SGBDR devraient se faire via des fonctions ou des classes qui encapsulent ce travail.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pour ma part, je me suis dit qu'il etait hors de question de reprendre
des pages et des pages de codes faites par des predecesseurs ou moi
meme. J'ai donc cree ca:
if(isset($_POST)) {
foreach($_POST as $key=>$val) {
//echo $key.'=>'.$val.'<p>';
$$key = $val;
}
}
Vous faites la même chose que register_global, vous serez donc
vulnérables aux mêmes problèmes.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais
pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Il n'est pas bon de polluer un espace global de variables limité, et
personnellement je ferais et encouragerais toujours les gens à faire
l'exact contraire de ce que vous faites.
Quand vous avez $age dans votre code, impossible de savoir si cela vient
du formulaire ou en interne de votre application, il faut vous farcir
toutes les lignes qui précèdent.
Si vous avez $_POST/$_GET/$_REQUEST['age'] vous savez sans ambiguités de
quoi vous parlez.
Pour les informations tirées de la base de données, elles devraient de
toute façon être de portée réduite, car les accès au SGBDR devraient se
faire via des fonctions ou des classes qui encapsulent ce travail.
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
Pour ma part, je me suis dit qu'il etait hors de question de reprendre des pages et des pages de codes faites par des predecesseurs ou moi meme. J'ai donc cree ca: if(isset($_POST)) { foreach($_POST as $key=>$val) { //echo $key.'=>'.$val.'<p>'; $$key = $val; } }
Vous faites la même chose que register_global, vous serez donc vulnérables aux mêmes problèmes.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Il n'est pas bon de polluer un espace global de variables limité, et personnellement je ferais et encouragerais toujours les gens à faire l'exact contraire de ce que vous faites.
Quand vous avez $age dans votre code, impossible de savoir si cela vient du formulaire ou en interne de votre application, il faut vous farcir toutes les lignes qui précèdent. Si vous avez $_POST/$_GET/$_REQUEST['age'] vous savez sans ambiguités de quoi vous parlez.
Pour les informations tirées de la base de données, elles devraient de toute façon être de portée réduite, car les accès au SGBDR devraient se faire via des fonctions ou des classes qui encapsulent ce travail.
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/> Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>
__marc.quinton__
bruno modulix wrote:
Autant je comprenais la raison d'être du $$hack sur $_POST ou $_GET ou etc pour éviter de corriger des centaines de lignes de code (qui auraient gagnées à être écrites plus proprement dès le début, mais bon, c'est un autre débat), autant là, à part gaspiller des ressources et rendre le code ch... la mort à maintenir, je ne vois vraiment pas l'intérêt de la manoeuvre.
avis partagé.
voila tout l'intéret de l'objet et de l'encapsulation d'un coté et ici l'extreme opposé ou bien des variables sont globales avec les difficultés suivantes :
* diffultés de compréhension pour qui n'est pas dans le contexte du logiciel,
* risque de collisions de variables. Si 2 fonctions ou pire 2 modules développés par 2 personnes différentes qui ne se connaissent pas, travaillent dans des services différents ... utilisent les memes noms de variables globales, il risque d'y avoir collision.
Il y a aussi ceux qui font de l'objet procédural avec des classes trop longues et pas spécialement découpée sur le plan conceptuel. Je pense a Thomas et la classe Menu.
Construire en objet, en modules c'est mieux. Mettre des variables globales dans tous les sens, c'est pratique pour un proto. Mais ca ne doit pas etre définitif. Mais souvent les protos sont transformés en produit sans evoluer au niveau de la conception.
bruno modulix wrote:
Autant je comprenais la raison d'être du $$hack sur $_POST ou $_GET ou
etc pour éviter de corriger des centaines de lignes de code (qui
auraient gagnées à être écrites plus proprement dès le début, mais bon,
c'est un autre débat), autant là, à part gaspiller des ressources et
rendre le code ch... la mort à maintenir, je ne vois vraiment pas
l'intérêt de la manoeuvre.
avis partagé.
voila tout l'intéret de l'objet et de l'encapsulation d'un coté
et ici l'extreme opposé ou bien des variables sont globales avec les
difficultés suivantes :
* diffultés de compréhension pour qui n'est pas dans le contexte
du logiciel,
* risque de collisions de variables. Si 2 fonctions ou pire
2 modules développés par 2 personnes différentes qui ne se
connaissent pas, travaillent dans des services différents ...
utilisent les memes noms de variables globales, il risque
d'y avoir collision.
Il y a aussi ceux qui font de l'objet procédural avec
des classes trop longues et pas spécialement découpée
sur le plan conceptuel. Je pense a Thomas et la
classe Menu.
Construire en objet, en modules c'est mieux. Mettre
des variables globales dans tous les sens, c'est pratique
pour un proto. Mais ca ne doit pas etre définitif. Mais souvent
les protos sont transformés en produit sans evoluer au
niveau de la conception.
Autant je comprenais la raison d'être du $$hack sur $_POST ou $_GET ou etc pour éviter de corriger des centaines de lignes de code (qui auraient gagnées à être écrites plus proprement dès le début, mais bon, c'est un autre débat), autant là, à part gaspiller des ressources et rendre le code ch... la mort à maintenir, je ne vois vraiment pas l'intérêt de la manoeuvre.
avis partagé.
voila tout l'intéret de l'objet et de l'encapsulation d'un coté et ici l'extreme opposé ou bien des variables sont globales avec les difficultés suivantes :
* diffultés de compréhension pour qui n'est pas dans le contexte du logiciel,
* risque de collisions de variables. Si 2 fonctions ou pire 2 modules développés par 2 personnes différentes qui ne se connaissent pas, travaillent dans des services différents ... utilisent les memes noms de variables globales, il risque d'y avoir collision.
Il y a aussi ceux qui font de l'objet procédural avec des classes trop longues et pas spécialement découpée sur le plan conceptuel. Je pense a Thomas et la classe Menu.
Construire en objet, en modules c'est mieux. Mettre des variables globales dans tous les sens, c'est pratique pour un proto. Mais ca ne doit pas etre définitif. Mais souvent les protos sont transformés en produit sans evoluer au niveau de la conception.
ftc
[SNIP]
J'ai donc cree ca: if(isset($_POST)) { foreach($_POST as $key=>$val) { //echo $key.'=>'.$val.'<p>'; $$key = $val; } }
if ( isset( $_POST ) ) extract( $_POST, EXTR_SKIP ); me semble plus concis et plus facile à lire et évide d'écraser des variables déjà définies.
[SNIP]
J'ai donc fait ceci:
$requete = "SELECT * FROM gest_parc"; $resultat = mysql_query($requete);
Tu n'as pas un problème de collision de noms de variables là ?
Il me semble bien qu'à chaque passage dans la boucle, tu écrases les données précédentes.
Tout ceci fonctionne a merveille. MAintenant la question que je me pose c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les applis qu'on trouve en open-source.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Avec ton premier code, tu te retrouves face à la même faille qu'avec register_globals à on, il faut donc penser à initialiser toutes les variables qui ne doivent pas être issues de $_POST.
Pour le deuxième code, tu es obligé de faire tout les traitements dans la boucle while, adieu la séparation code-affichage. Sans compter que je ne vois pas bien la différence entre utiliser $row['id'] ou $id à part que l'utilisation de $row['id'] sera quand même beaucoup plus lisible puisqu'on voit immédiatement d'ou il vient.
Quand j'ai commencé à programmer en Perl ( ça commence à dater unpeu maintenant ), j'utilisais pas mal ce genre de choses, l'habitude m'en est passée, avec le passage au PHP je n'ai jamais eu à m'en servir.
Résultat: le code est mille fois plus facile à écrire et à lire, sans compter les failles de sécurité que ce genre de pratique peut engendrer.
[SNIP]
J'ai donc cree ca:
if(isset($_POST)) {
foreach($_POST as $key=>$val) {
//echo $key.'=>'.$val.'<p>';
$$key = $val;
}
}
if ( isset( $_POST ) ) extract( $_POST, EXTR_SKIP );
me semble plus concis et plus facile à lire et évide d'écraser des
variables déjà définies.
[SNIP]
J'ai donc fait ceci:
$requete = "SELECT * FROM gest_parc";
$resultat = mysql_query($requete);
Tu n'as pas un problème de collision de noms de variables là ?
Il me semble bien qu'à chaque passage dans la boucle, tu écrases les
données précédentes.
Tout ceci fonctionne a merveille. MAintenant la question que je me pose
c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les
applis qu'on trouve en open-source.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a
l'encontre de l'efficacite ou d'un certain "bon procede".
Avec ton premier code, tu te retrouves face à la même faille qu'avec
register_globals à on, il faut donc penser à initialiser toutes les
variables qui ne doivent pas être issues de $_POST.
Pour le deuxième code, tu es obligé de faire tout les traitements dans
la boucle while, adieu la séparation code-affichage. Sans compter que je
ne vois pas bien la différence entre utiliser $row['id'] ou $id à part
que l'utilisation de $row['id'] sera quand même beaucoup plus lisible
puisqu'on voit immédiatement d'ou il vient.
Quand j'ai commencé à programmer en Perl ( ça commence à dater unpeu
maintenant ), j'utilisais pas mal ce genre de choses, l'habitude m'en
est passée, avec le passage au PHP je n'ai jamais eu à m'en servir.
Résultat: le code est mille fois plus facile à écrire et à lire, sans
compter les failles de sécurité que ce genre de pratique peut engendrer.
Tu n'as pas un problème de collision de noms de variables là ?
Il me semble bien qu'à chaque passage dans la boucle, tu écrases les données précédentes.
Tout ceci fonctionne a merveille. MAintenant la question que je me pose c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les applis qu'on trouve en open-source.
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Avec ton premier code, tu te retrouves face à la même faille qu'avec register_globals à on, il faut donc penser à initialiser toutes les variables qui ne doivent pas être issues de $_POST.
Pour le deuxième code, tu es obligé de faire tout les traitements dans la boucle while, adieu la séparation code-affichage. Sans compter que je ne vois pas bien la différence entre utiliser $row['id'] ou $id à part que l'utilisation de $row['id'] sera quand même beaucoup plus lisible puisqu'on voit immédiatement d'ou il vient.
Quand j'ai commencé à programmer en Perl ( ça commence à dater unpeu maintenant ), j'utilisais pas mal ce genre de choses, l'habitude m'en est passée, avec le passage au PHP je n'ai jamais eu à m'en servir.
Résultat: le code est mille fois plus facile à écrire et à lire, sans compter les failles de sécurité que ce genre de pratique peut engendrer.
Olivier Miakinen
Vous vous souvenez quand le register_global faisait des siennes.
Tu veux dire, quand il a été décidé de mettre register_global à OFF pour éviter un possible trou de sécurité dans les applis mal codées ?
Pour un grand nombre de developpeurs il a fallu reprendre le code notamment pour les formulaire et changer: $toto (issu du champs de formulaire ... name="toto">) en $_POST['toto'].
Oui, ou plus simplement en $_REQUEST['toto']
Pour ma part, je me suis dit qu'il etait hors de question de reprendre des pages et des pages de codes faites par des predecesseurs ou moi meme. J'ai donc cree ca: if(isset($_POST)) { foreach($_POST as $key=>$val) { //echo $key.'=>'.$val.'<p>'; $$key = $val; } }
Que je mettais en haut de toutes mes pages. Et ca donctionne tres bien.
Oui, tu te retrouves avec le comportement d'avant, et sa faille possible. Pourquoi dans ce cas ne pas simplement remettre l'option register_global à ON ?
[...]
Tout ceci fonctionne a merveille. MAintenant la question que je me pose c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les applis qu'on trouve en open-source.
Peut-être que les codeurs qui publient sur le net préfèrent combler les failles de sécurité plutôt que les réouvrir ?
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Vous vous souvenez quand le register_global faisait des siennes.
Tu veux dire, quand il a été décidé de mettre register_global à OFF pour
éviter un possible trou de sécurité dans les applis mal codées ?
Pour un grand nombre de developpeurs il a fallu reprendre le code
notamment pour les formulaire et changer:
$toto (issu du champs de formulaire ... name="toto">)
en
$_POST['toto'].
Oui, ou plus simplement en $_REQUEST['toto']
Pour ma part, je me suis dit qu'il etait hors de question de reprendre des
pages et des pages de codes faites par des predecesseurs ou moi meme.
J'ai donc cree ca:
if(isset($_POST)) {
foreach($_POST as $key=>$val) {
//echo $key.'=>'.$val.'<p>';
$$key = $val;
}
}
Que je mettais en haut de toutes mes pages. Et ca donctionne tres bien.
Oui, tu te retrouves avec le comportement d'avant, et sa faille
possible. Pourquoi dans ce cas ne pas simplement remettre l'option
register_global à ON ?
[...]
Tout ceci fonctionne a merveille. MAintenant la question que je me pose
c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les
applis qu'on trouve en open-source.
Peut-être que les codeurs qui publient sur le net préfèrent combler les
failles de sécurité plutôt que les réouvrir ?
--
Olivier Miakinen
Non, monsieur le juge, je vous le jure : jamais je n'ai cité
Bruxelles dans ma signature.
Vous vous souvenez quand le register_global faisait des siennes.
Tu veux dire, quand il a été décidé de mettre register_global à OFF pour éviter un possible trou de sécurité dans les applis mal codées ?
Pour un grand nombre de developpeurs il a fallu reprendre le code notamment pour les formulaire et changer: $toto (issu du champs de formulaire ... name="toto">) en $_POST['toto'].
Oui, ou plus simplement en $_REQUEST['toto']
Pour ma part, je me suis dit qu'il etait hors de question de reprendre des pages et des pages de codes faites par des predecesseurs ou moi meme. J'ai donc cree ca: if(isset($_POST)) { foreach($_POST as $key=>$val) { //echo $key.'=>'.$val.'<p>'; $$key = $val; } }
Que je mettais en haut de toutes mes pages. Et ca donctionne tres bien.
Oui, tu te retrouves avec le comportement d'avant, et sa faille possible. Pourquoi dans ce cas ne pas simplement remettre l'option register_global à ON ?
[...]
Tout ceci fonctionne a merveille. MAintenant la question que je me pose c'est que je n'ai jamais vu ce genre de code sur le net ni meme dans les applis qu'on trouve en open-source.
Peut-être que les codeurs qui publient sur le net préfèrent combler les failles de sécurité plutôt que les réouvrir ?
-- Olivier Miakinen Non, monsieur le juge, je vous le jure : jamais je n'ai cité Bruxelles dans ma signature.
Alexandre
Salut,
m'enfin, faut pas voir le mal hein, j'te vois t'énerver sur le clavier, moi je ne fais que demander.
Ce qui m'a etonne c'est de ne pas voir ca sur le net et voir des centaines de personnes reprendre des pages et des pages de code.
Mais pour te répondre:
(snip)
foreach($row as $key=>$val) { $$key = $val; } }
Ouais. Bien. Bravo. <imaginons> Je viens d'hériter de ton projet, et je suis vachement content de devoir consulter le schéma de la base et les valeurs possibles de $_GET et $_POST (que tu a traité de la même façon) pour savoir qui est qui, qui vient d'où, et pourquoi tout ça bugge de partout depuis la modif dernière modif qui semblait pourtant bien innocente à première vue...
Vraiment vachement content. </imaginons>
pour ma part j'utilise une "grammaire" dans mes projets. Quand je fais un projet je l'accompagne d'une "doc" en quelque sorte. Et on peut y trouver par exemple qu'un champ texte je vais le nommer à la maniere de VB (enfin quand j'ai commence sous VB c'est ce que je faisais): txtNom txtPrenom par exemple.
Ainsi ca repond a ce que tu dit quand tu veux savoir d'ou vient une variable, idem pour $_GET, je donne un prefix à mes variables que je passe par la methode GET.
Donc aucune difficulte a reprendre.
Pour continuer:
Ce qui m'evite de faire: while ($row=mysql_fetch_object($resultat)){ $id = $row->id; $nom = $row->nom; }
Quel est le problème avec $row->id (ou $row['id'], etc) ? Tu a déjà tes valeurs disponibles et accessibles avec un identifiant clair et lisible, *explicite*, et cantonné à un espace de nommage bien délimité ce qui évite bien des effets de bords intempestifs.
La ok je suis d'accord c'est une facon de faire, en ce qui me concerne je deteste bosser avec mes variables dans un tableau associatif, j'ai trop peur de faire une connerie avec une quote ou une double quote ou autre. C'est pourquoi j'aime ecrire: $id = $row->id;
Mais quand on a 70 champs dans une table et qu'on veut TOUT, je trouve ma soluce plutot pas mal.
Ma question portait egalement sur la securite ou la rapidite d'exécution mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne sais pas vraiment si je fais une connerie ou pas.
Mes deux centimes...
Ca veut dire quoi?
Alex
Salut,
m'enfin, faut pas voir le mal hein, j'te vois t'énerver sur le clavier, moi
je ne fais que demander.
Ce qui m'a etonne c'est de ne pas voir ca sur le net et voir des centaines
de personnes reprendre des pages et des pages de code.
Mais pour te répondre:
(snip)
foreach($row as $key=>$val) {
$$key = $val;
}
}
Ouais. Bien. Bravo.
<imaginons>
Je viens d'hériter de ton projet, et je suis vachement content de devoir
consulter le schéma de la base et les valeurs possibles de $_GET et
$_POST (que tu a traité de la même façon) pour savoir qui est qui, qui
vient d'où, et pourquoi tout ça bugge de partout depuis la modif
dernière modif qui semblait pourtant bien innocente à première vue...
Vraiment vachement content.
</imaginons>
pour ma part j'utilise une "grammaire" dans mes projets. Quand je fais un
projet je l'accompagne d'une "doc" en quelque sorte. Et on peut y trouver
par exemple qu'un champ texte je vais le nommer à la maniere de VB (enfin
quand j'ai commence sous VB c'est ce que je faisais):
txtNom
txtPrenom
par exemple.
Ainsi ca repond a ce que tu dit quand tu veux savoir d'ou vient une
variable, idem pour $_GET, je donne un prefix à mes variables que je passe
par la methode GET.
Donc aucune difficulte a reprendre.
Pour continuer:
Ce qui m'evite de faire:
while ($row=mysql_fetch_object($resultat)){
$id = $row->id;
$nom = $row->nom;
}
Quel est le problème avec $row->id (ou $row['id'], etc) ? Tu a déjà tes
valeurs disponibles et accessibles avec un identifiant clair et lisible,
*explicite*, et cantonné à un espace de nommage bien délimité ce qui
évite bien des effets de bords intempestifs.
La ok je suis d'accord c'est une facon de faire, en ce qui me concerne je
deteste bosser avec mes variables dans un tableau associatif, j'ai trop peur
de faire une connerie avec une quote ou une double quote ou autre. C'est
pourquoi j'aime ecrire:
$id = $row->id;
Mais quand on a 70 champs dans une table et qu'on veut TOUT, je trouve ma
soluce plutot pas mal.
Ma question portait egalement sur la securite ou la rapidite d'exécution
mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne
sais pas vraiment si je fais une connerie ou pas.
m'enfin, faut pas voir le mal hein, j'te vois t'énerver sur le clavier, moi je ne fais que demander.
Ce qui m'a etonne c'est de ne pas voir ca sur le net et voir des centaines de personnes reprendre des pages et des pages de code.
Mais pour te répondre:
(snip)
foreach($row as $key=>$val) { $$key = $val; } }
Ouais. Bien. Bravo. <imaginons> Je viens d'hériter de ton projet, et je suis vachement content de devoir consulter le schéma de la base et les valeurs possibles de $_GET et $_POST (que tu a traité de la même façon) pour savoir qui est qui, qui vient d'où, et pourquoi tout ça bugge de partout depuis la modif dernière modif qui semblait pourtant bien innocente à première vue...
Vraiment vachement content. </imaginons>
pour ma part j'utilise une "grammaire" dans mes projets. Quand je fais un projet je l'accompagne d'une "doc" en quelque sorte. Et on peut y trouver par exemple qu'un champ texte je vais le nommer à la maniere de VB (enfin quand j'ai commence sous VB c'est ce que je faisais): txtNom txtPrenom par exemple.
Ainsi ca repond a ce que tu dit quand tu veux savoir d'ou vient une variable, idem pour $_GET, je donne un prefix à mes variables que je passe par la methode GET.
Donc aucune difficulte a reprendre.
Pour continuer:
Ce qui m'evite de faire: while ($row=mysql_fetch_object($resultat)){ $id = $row->id; $nom = $row->nom; }
Quel est le problème avec $row->id (ou $row['id'], etc) ? Tu a déjà tes valeurs disponibles et accessibles avec un identifiant clair et lisible, *explicite*, et cantonné à un espace de nommage bien délimité ce qui évite bien des effets de bords intempestifs.
La ok je suis d'accord c'est une facon de faire, en ce qui me concerne je deteste bosser avec mes variables dans un tableau associatif, j'ai trop peur de faire une connerie avec une quote ou une double quote ou autre. C'est pourquoi j'aime ecrire: $id = $row->id;
Mais quand on a 70 champs dans une table et qu'on veut TOUT, je trouve ma soluce plutot pas mal.
Ma question portait egalement sur la securite ou la rapidite d'exécution mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne sais pas vraiment si je fais une connerie ou pas.
Mes deux centimes...
Ca veut dire quoi?
Alex
Denis Beauregard
Le 16 Jun 2005 13:52:09 GMT, Alexandre
écrivait dans fr.comp.lang.php:
Mais quand on a 70 champs dans une table et qu'on veut TOUT, je trouve ma soluce plutot pas mal.
Ma solution est un peu différente quoiqu'elle bouffe autant de ressources sans doute.
Ainsi, au moins, je n'ai que des paramètres prévus.
Ma question portait egalement sur la securite ou la rapidite d'exécution mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne sais pas vraiment si je fais une connerie ou pas.
Un des dangers, c'est d'introduire d'autres variables qui font changer le fonctionnement du code. Cela doit arriver plutôt dans les scripts recyclés.
Un autre, c'est qu'on peut remplacer des variables de système.
Ou encore de provoquer le plantage du script et avec de la malchance, c'est le .php pur qui apparaît (mais là, faut être très malchanceux).
Mes deux centimes...
Ca veut dire quoi?
Un anglicisme: my 2 cents.
En français pur, on dirait plutôt:
Mon grain de sel
Denis
Le 16 Jun 2005 13:52:09 GMT, Alexandre
<astalavista@ANTIGROSSPAMMAGEnetcourrier.comANTIZZZPPPAAMMMZZZ>
écrivait dans fr.comp.lang.php:
Mais quand on a 70 champs dans une table et qu'on veut TOUT, je trouve ma
soluce plutot pas mal.
Ma solution est un peu différente quoiqu'elle bouffe autant de
ressources sans doute.
Ainsi, au moins, je n'ai que des paramètres prévus.
Ma question portait egalement sur la securite ou la rapidite d'exécution
mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne
sais pas vraiment si je fais une connerie ou pas.
Un des dangers, c'est d'introduire d'autres variables qui font
changer le fonctionnement du code. Cela doit arriver plutôt dans
les scripts recyclés.
Un autre, c'est qu'on peut remplacer des variables de système.
Ou encore de provoquer le plantage du script et avec de la
malchance, c'est le .php pur qui apparaît (mais là, faut être
très malchanceux).
Ainsi, au moins, je n'ai que des paramètres prévus.
Ma question portait egalement sur la securite ou la rapidite d'exécution mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne sais pas vraiment si je fais une connerie ou pas.
Un des dangers, c'est d'introduire d'autres variables qui font changer le fonctionnement du code. Cela doit arriver plutôt dans les scripts recyclés.
Un autre, c'est qu'on peut remplacer des variables de système.
Ou encore de provoquer le plantage du script et avec de la malchance, c'est le .php pur qui apparaît (mais là, faut être très malchanceux).
Mes deux centimes...
Ca veut dire quoi?
Un anglicisme: my 2 cents.
En français pur, on dirait plutôt:
Mon grain de sel
Denis
bruno modulix
Alexandre wrote:
Salut,
m'enfin, faut pas voir le mal hein, j'te vois t'énerver sur le clavier, moi je ne fais que demander.
Et moi je ne fais que réponde !-)
Ce qui m'a etonne c'est de ne pas voir ca sur le net et voir des centaines de personnes reprendre des pages et des pages de code.
He oui...
(snip)
pour ma part j'utilise une "grammaire" dans mes projets. Quand je fais un projet je l'accompagne d'une "doc" en quelque sorte. Et on peut y trouver par exemple qu'un champ texte je vais le nommer à la maniere de VB
yuck :(
Ainsi ca repond a ce que tu dit quand tu veux savoir d'ou vient une variable, idem pour $_GET, je donne un prefix à mes variables que je passe par la methode GET.
Donc aucune difficulte a reprendre.
Ok, c'est déjà ça.
Mais ça n'empêche pas les problèmes potentiels d'écrasement sauvage de variables. Problèmes accidentels ou non... (je pense surtout aux variables $_POST/$_GET)
Quel est le problème avec $row->id (ou $row['id'], etc) ?
La ok je suis d'accord c'est une facon de faire, en ce qui me concerne je deteste bosser avec mes variables dans un tableau associatif,
Moi j'aime bien. Surtout dans un langage aussi modulaire (arf arf arf) que PHP.
j'ai trop peur de faire une connerie avec une quote ou une double quote ou autre.
Quelle connerie ? Quel risque supplémentaire par rapport à une typo sur le nom de la variable ? Franchement, de ce point de vue, je ne vois pas la différence profonde.
Il y a suffisament de conneries possibles, pas la peine d'en rajouter :-/
Ma question portait egalement sur la securite pour ce qui est des variables issues de la requête, les utiliser sans
contrôle est déjà une mauvaise idée, alors leur donner en plus une chance d'écraser d'autres variables... no comment.
ou la rapidite d'exécution Bin, dupliquer inutilement toutes les variables $_REQUEST et tout ce qui
vient de la DB, ça prend du temps et des ressources... pour rien.
mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne sais pas vraiment si je fais une connerie ou pas.
A mon avis, oui.
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
Alexandre wrote:
Salut,
m'enfin, faut pas voir le mal hein, j'te vois t'énerver sur le clavier, moi
je ne fais que demander.
Et moi je ne fais que réponde !-)
Ce qui m'a etonne c'est de ne pas voir ca sur le net et voir des centaines
de personnes reprendre des pages et des pages de code.
He oui...
(snip)
pour ma part j'utilise une "grammaire" dans mes projets. Quand je fais un
projet je l'accompagne d'une "doc" en quelque sorte. Et on peut y trouver
par exemple qu'un champ texte je vais le nommer à la maniere de VB
yuck :(
Ainsi ca repond a ce que tu dit quand tu veux savoir d'ou vient une
variable, idem pour $_GET, je donne un prefix à mes variables que je passe
par la methode GET.
Donc aucune difficulte a reprendre.
Ok, c'est déjà ça.
Mais ça n'empêche pas les problèmes potentiels d'écrasement sauvage de
variables. Problèmes accidentels ou non... (je pense surtout aux
variables $_POST/$_GET)
Quel est le problème avec $row->id (ou $row['id'], etc) ?
La ok je suis d'accord c'est une facon de faire, en ce qui me concerne je
deteste bosser avec mes variables dans un tableau associatif,
Moi j'aime bien. Surtout dans un langage aussi modulaire (arf arf arf)
que PHP.
j'ai trop peur
de faire une connerie avec une quote ou une double quote ou autre.
Quelle connerie ? Quel risque supplémentaire par rapport à une typo sur
le nom de la variable ? Franchement, de ce point de vue, je ne vois pas
la différence profonde.
Il y a suffisament de conneries possibles, pas la peine d'en rajouter :-/
Ma question portait egalement sur la securite
pour ce qui est des variables issues de la requête, les utiliser sans
contrôle est déjà une mauvaise idée, alors leur donner en plus une
chance d'écraser d'autres variables... no comment.
ou la rapidite d'exécution
Bin, dupliquer inutilement toutes les variables $_REQUEST et tout ce qui
vient de la DB, ça prend du temps et des ressources... pour rien.
mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne
sais pas vraiment si je fais une connerie ou pas.
A mon avis, oui.
--
bruno desthuilliers
ruby -e "print 'onurb@xiludom.gro'.split('@').collect{|p|
p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
m'enfin, faut pas voir le mal hein, j'te vois t'énerver sur le clavier, moi je ne fais que demander.
Et moi je ne fais que réponde !-)
Ce qui m'a etonne c'est de ne pas voir ca sur le net et voir des centaines de personnes reprendre des pages et des pages de code.
He oui...
(snip)
pour ma part j'utilise une "grammaire" dans mes projets. Quand je fais un projet je l'accompagne d'une "doc" en quelque sorte. Et on peut y trouver par exemple qu'un champ texte je vais le nommer à la maniere de VB
yuck :(
Ainsi ca repond a ce que tu dit quand tu veux savoir d'ou vient une variable, idem pour $_GET, je donne un prefix à mes variables que je passe par la methode GET.
Donc aucune difficulte a reprendre.
Ok, c'est déjà ça.
Mais ça n'empêche pas les problèmes potentiels d'écrasement sauvage de variables. Problèmes accidentels ou non... (je pense surtout aux variables $_POST/$_GET)
Quel est le problème avec $row->id (ou $row['id'], etc) ?
La ok je suis d'accord c'est une facon de faire, en ce qui me concerne je deteste bosser avec mes variables dans un tableau associatif,
Moi j'aime bien. Surtout dans un langage aussi modulaire (arf arf arf) que PHP.
j'ai trop peur de faire une connerie avec une quote ou une double quote ou autre.
Quelle connerie ? Quel risque supplémentaire par rapport à une typo sur le nom de la variable ? Franchement, de ce point de vue, je ne vois pas la différence profonde.
Il y a suffisament de conneries possibles, pas la peine d'en rajouter :-/
Ma question portait egalement sur la securite pour ce qui est des variables issues de la requête, les utiliser sans
contrôle est déjà une mauvaise idée, alors leur donner en plus une chance d'écraser d'autres variables... no comment.
ou la rapidite d'exécution Bin, dupliquer inutilement toutes les variables $_REQUEST et tout ce qui
vient de la DB, ça prend du temps et des ressources... pour rien.
mais aussi sur la "philosophie" (chose a laquelle tu as repondu). La je ne sais pas vraiment si je fais une connerie ou pas.
A mon avis, oui.
-- bruno desthuilliers ruby -e "print ''.split('@').collect{|p| p.split('.').collect{|w| w.reverse}.join('.')}.join('@')"
loufoque
Alexandre a dit le 16/06/2005 à 13:25:
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Je vais te donner mon avis : ça pue grave.
Alexandre a dit le 16/06/2005 à 13:25:
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a
l'encontre de l'efficacite ou d'un certain "bon procede".
Je me demandais alors si j'adoptais une bonne methode, si je n'allais pas a l'encontre de l'efficacite ou d'un certain "bon procede".
Je vais te donner mon avis : ça pue grave.
Nadine St-Amand
Oui, tu te retrouves avec le comportement d'avant, et sa faille possible.
La faille viendrait de variables utilisees sans etre initialisees, si le programmeur sait ce qu'il fait, je pense que il n'a pas besoin de register off.
Si le programmeur ne sait pas ce qu'il fait, je pense que register off ne le sauvera pas de toute facon
(c'est ma philosophie)
Register off n'a pas la propriete d'empecher une injection sql
Pourquoi dans ce cas ne pas simplement remettre l'option
register_global à ON ?
Parce qu'il ne controle pas necessairement ou sera execute son code par la suite.
-- Nadine St-Amand
Oui, tu te retrouves avec le comportement d'avant, et sa faille
possible.
La faille viendrait de variables utilisees sans etre initialisees,
si le programmeur sait ce qu'il fait, je pense que il n'a pas besoin de
register off.
Si le programmeur ne sait pas ce qu'il fait,
je pense que register off ne le sauvera pas de toute facon
(c'est ma philosophie)
Register off n'a pas la propriete d'empecher une injection sql
Pourquoi dans ce cas ne pas simplement remettre l'option
register_global à ON ?
Parce qu'il ne controle pas necessairement
ou sera execute son code par la suite.
Oui, tu te retrouves avec le comportement d'avant, et sa faille possible.
La faille viendrait de variables utilisees sans etre initialisees, si le programmeur sait ce qu'il fait, je pense que il n'a pas besoin de register off.
Si le programmeur ne sait pas ce qu'il fait, je pense que register off ne le sauvera pas de toute facon
(c'est ma philosophie)
Register off n'a pas la propriete d'empecher une injection sql
Pourquoi dans ce cas ne pas simplement remettre l'option
register_global à ON ?
Parce qu'il ne controle pas necessairement ou sera execute son code par la suite.
