Bonjour,
Apres avoir essayer de comprendre la fonctionnement d'un CRUD
(create,read,update,delete) et vu la complexité, j'ai commencé un
script dont je n'arrive pas a le faire fonctionner de maniere assez
belle.
Les données viennent d'un formulaire avec POST et les champs Nom,
Prenom, Adresse.
Le probleme est ce "," qui reste a la fin, qui me gene.
en effet,
$a contient à la fin de la boucle Nom,Prenom,Adresse,
$b contient à la fin de chaine Jean, Dupont, 10 rue des etc ,
J'ai penser a faire une expressions reguliere pour les retirer mais ne
suis pas certains que c'est la meilleur solutions.
Avez vous une idée plus simple ?
Merci de votre aide.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Le probleme est ce "," qui reste a la fin, qui me gene. en effet, $a contient à la fin de la boucle Nom,Prenom,Adresse, $b contient à la fin de chaine Jean, Dupont, 10 rue des etc ,
J'ai penser a faire une expressions reguliere pour les retirer mais ne suis pas certains que c'est la meilleur solutions.
Avez vous une idée plus simple ?
Le plus simple :
http://fr.php.net/rtrim
$str = rtrim($str, ",");
Une autre possibilité consiste à mettre chaque virgule avant plutôt qu'après, et ensuite :
$str = substr($str, 1);
Enfin, tu peux aussi tester dans ta boucle si la chaîne est vide ou pas avant d'insérer une éventuelle virgule, par exemple :
Mais tu devrais quand même faire gaffe à ce qui peut se trouver dans $_POST avant de l'insérer dans ta base de données...
Le probleme est ce "," qui reste a la fin, qui me gene.
en effet,
$a contient à la fin de la boucle Nom,Prenom,Adresse,
$b contient à la fin de chaine Jean, Dupont, 10 rue des etc ,
J'ai penser a faire une expressions reguliere pour les retirer mais ne
suis pas certains que c'est la meilleur solutions.
Avez vous une idée plus simple ?
Le plus simple :
http://fr.php.net/rtrim
$str = rtrim($str, ",");
Une autre possibilité consiste à mettre chaque virgule avant plutôt
qu'après, et ensuite :
$str = substr($str, 1);
Enfin, tu peux aussi tester dans ta boucle si la chaîne est vide ou pas
avant d'insérer une éventuelle virgule, par exemple :
Le probleme est ce "," qui reste a la fin, qui me gene. en effet, $a contient à la fin de la boucle Nom,Prenom,Adresse, $b contient à la fin de chaine Jean, Dupont, 10 rue des etc ,
J'ai penser a faire une expressions reguliere pour les retirer mais ne suis pas certains que c'est la meilleur solutions.
Avez vous une idée plus simple ?
Le plus simple :
http://fr.php.net/rtrim
$str = rtrim($str, ",");
Une autre possibilité consiste à mettre chaque virgule avant plutôt qu'après, et ensuite :
$str = substr($str, 1);
Enfin, tu peux aussi tester dans ta boucle si la chaîne est vide ou pas avant d'insérer une éventuelle virgule, par exemple :
Mais tu devrais quand même faire gaffe à ce qui peut se trouver dans $_POST avant de l'insérer dans ta base de données...
Clairement il faut toujours valider et contrôler les données saisies par l'utilisateur avant d'exécuter une requête.
John GALLET
Bonjour,
(create,read,update,delete) et vu la complexité, j'ai commencé un script dont je n'arrive pas a le faire fonctionner de maniere assez belle.
Attention au piège de "l'esthète du code". On demande à du code d'être avant tout fonctionnel, sécurisé et facile à maintenir.
Le probleme est ce "," qui reste a la fin, qui me gene.
Non, se débarasser de la virgule finale, c'est deux lignes de code avec un appel à strrpos pour trouver son emplacement ou un substring avec un strlen avant : on sait que c'est nécessairement le DERNIER caractère ET qu'il existe, par constuction, donc c'est "trivial et laissé au lecteur comme exercice d'application immédiate" (ça me fait toujours marrer de lire ce genre de conneries dans les bouquins un peu conceptuels/hype).
Ou comme me l'apprend Olivier (je viens de voir que c'est depuis la 4.1, eh oui, je suis pas à jour de mon manuel) le paramètre optionnel de rtrim est encore plus élégant en php.
Le *vrai* problème c'est de savoir si ce genre de constructions automatiques a un sens ou pas. Et pour moi il n'en a pas. Par exemple, qu'est-ce qui va se passer s'il manque une variable ? Et le jour où on a besoin d'ajouter un champ hidden dans le formulaire ? Ou si on ajoute un champ NULLable dans la table, ou un timestamp de modification/insertion qui prendra typiquement l'heure système comme valeur ? Ca va être un beau bordel. Et je ne parle même pas d'écrire du SQL correct (i.e. les numériques ne sont *PAS* entre ', et actuellement ça m'étonnerait que ça marche pour insérer des strings, manque des ' autour des champs string SQL).
Avez vous une idée plus simple ?
Ecrire un générateur de code (personnellement je fais ça en awk) qui analyse le create table pour générer automatiquement du code PHP faisant la construction de requêtes SQL a un sens. Poussé en méthode de développement générique, ça donne un ORM (on en a parlé en septembre dernier : http://propel.phpdb.org/trac/ par exemple).
Donc un bon vieil INSERT codé 'en dur' en ayant auparavant fait tout le nécessaire de filtrage de variables c'est une idée "plus simple".
a++; JG
Bonjour,
(create,read,update,delete) et vu la complexité, j'ai commencé un
script dont je n'arrive pas a le faire fonctionner de maniere assez
belle.
Attention au piège de "l'esthète du code". On demande à du code d'être
avant tout fonctionnel, sécurisé et facile à maintenir.
Le probleme est ce "," qui reste a la fin, qui me gene.
Non, se débarasser de la virgule finale, c'est deux lignes de code avec un
appel à strrpos pour trouver son emplacement ou un substring avec un
strlen avant : on sait que c'est nécessairement le DERNIER caractère ET
qu'il existe, par constuction, donc c'est "trivial et laissé au lecteur
comme exercice d'application immédiate" (ça me fait toujours marrer de
lire ce genre de conneries dans les bouquins un peu conceptuels/hype).
Ou comme me l'apprend Olivier (je viens de voir que c'est depuis la 4.1,
eh oui, je suis pas à jour de mon manuel) le paramètre optionnel de rtrim
est encore plus élégant en php.
Le *vrai* problème c'est de savoir si ce genre de constructions
automatiques a un sens ou pas. Et pour moi il n'en a pas. Par exemple,
qu'est-ce qui va se passer s'il manque une variable ? Et le jour où on a
besoin d'ajouter un champ hidden dans le formulaire ? Ou si on ajoute un
champ NULLable dans la table, ou un timestamp de modification/insertion
qui prendra typiquement l'heure système comme valeur ? Ca va être un beau
bordel. Et je ne parle même pas d'écrire du SQL correct (i.e. les
numériques ne sont *PAS* entre ', et actuellement ça m'étonnerait que ça
marche pour insérer des strings, manque des ' autour des champs string
SQL).
Avez vous une idée plus simple ?
Ecrire un générateur de code (personnellement je fais ça en awk) qui
analyse le create table pour générer automatiquement du code PHP faisant
la construction de requêtes SQL a un sens. Poussé en méthode de
développement générique, ça donne un ORM (on en a parlé en septembre
dernier : http://propel.phpdb.org/trac/ par exemple).
Donc un bon vieil INSERT codé 'en dur' en ayant auparavant fait tout le
nécessaire de filtrage de variables c'est une idée "plus simple".
(create,read,update,delete) et vu la complexité, j'ai commencé un script dont je n'arrive pas a le faire fonctionner de maniere assez belle.
Attention au piège de "l'esthète du code". On demande à du code d'être avant tout fonctionnel, sécurisé et facile à maintenir.
Le probleme est ce "," qui reste a la fin, qui me gene.
Non, se débarasser de la virgule finale, c'est deux lignes de code avec un appel à strrpos pour trouver son emplacement ou un substring avec un strlen avant : on sait que c'est nécessairement le DERNIER caractère ET qu'il existe, par constuction, donc c'est "trivial et laissé au lecteur comme exercice d'application immédiate" (ça me fait toujours marrer de lire ce genre de conneries dans les bouquins un peu conceptuels/hype).
Ou comme me l'apprend Olivier (je viens de voir que c'est depuis la 4.1, eh oui, je suis pas à jour de mon manuel) le paramètre optionnel de rtrim est encore plus élégant en php.
Le *vrai* problème c'est de savoir si ce genre de constructions automatiques a un sens ou pas. Et pour moi il n'en a pas. Par exemple, qu'est-ce qui va se passer s'il manque une variable ? Et le jour où on a besoin d'ajouter un champ hidden dans le formulaire ? Ou si on ajoute un champ NULLable dans la table, ou un timestamp de modification/insertion qui prendra typiquement l'heure système comme valeur ? Ca va être un beau bordel. Et je ne parle même pas d'écrire du SQL correct (i.e. les numériques ne sont *PAS* entre ', et actuellement ça m'étonnerait que ça marche pour insérer des strings, manque des ' autour des champs string SQL).
Avez vous une idée plus simple ?
Ecrire un générateur de code (personnellement je fais ça en awk) qui analyse le create table pour générer automatiquement du code PHP faisant la construction de requêtes SQL a un sens. Poussé en méthode de développement générique, ça donne un ORM (on en a parlé en septembre dernier : http://propel.phpdb.org/trac/ par exemple).
Donc un bon vieil INSERT codé 'en dur' en ayant auparavant fait tout le nécessaire de filtrage de variables c'est une idée "plus simple".
a++; JG
geo75
Le *vrai* problème c'est de savoir si ce genre de constructions automatiques a un sens ou pas. Et pour moi il n'en a pas. Par exemple, qu'est-ce qui va se passer s'il manque une variable ? Et le jour où on a besoin d'ajouter un champ hidden dans le formulaire ? Ou si on ajoute un champ NULLable dans la table, ou un timestamp de modification/insertion qui prendra typiquement l'heure système comme valeur ? Ca va être un beau bordel. Et je ne parle même pas d'écrire du SQL correct (i.e. les numériques ne sont *PAS* entre ', et actuellement ça m'étonnerait que ça marche pour insérer des strings, manque des ' autour des champs string SQL).
Bonjour,
Merci pour votre intervention, je me pose des questions en effet.
Mon idée de départ est que j'ai 9 formulaire a mettre à jour, alors je me suis dit autant faire une fonction qui mouline et injecte dans la base de donnée, bien sur en prenant le soin de verifier avant l'insert. Il est vrai que le CRUD est teriblement compliqué à mettre en oeuvre(enfin pour moi)
Dans le cas présent, je pense que si le formulaire contient un champs hidden, il sera aussi inseré.
Donc un bon vieil INSERT codé 'en dur' en ayant auparavant fait tout le nécessaire de filtrage de variables c'est une idée "plus simple".
C'est assez trivial, mais en cas d'erreur il faudrat certainement changer dans tous les formulaires. Pour 9 ca ira, mais ca va augmenter rapidement.
Le *vrai* problème c'est de savoir si ce genre de constructions
automatiques a un sens ou pas. Et pour moi il n'en a pas. Par exemple,
qu'est-ce qui va se passer s'il manque une variable ? Et le jour où on a
besoin d'ajouter un champ hidden dans le formulaire ? Ou si on ajoute un
champ NULLable dans la table, ou un timestamp de modification/insertion
qui prendra typiquement l'heure système comme valeur ? Ca va être un beau
bordel. Et je ne parle même pas d'écrire du SQL correct (i.e. les
numériques ne sont *PAS* entre ', et actuellement ça m'étonnerait que ça
marche pour insérer des strings, manque des ' autour des champs string
SQL).
Bonjour,
Merci pour votre intervention, je me pose des questions en effet.
Mon idée de départ est que j'ai 9 formulaire a mettre à jour, alors
je me suis dit autant faire une fonction qui mouline et injecte dans la
base de donnée, bien sur en prenant le soin de verifier avant
l'insert. Il est vrai que le CRUD est teriblement compliqué à mettre
en oeuvre(enfin pour moi)
Dans le cas présent, je pense que si le formulaire contient un champs
hidden, il sera aussi inseré.
Donc un bon vieil INSERT codé 'en dur' en ayant auparavant fait tout le
nécessaire de filtrage de variables c'est une idée "plus simple".
C'est assez trivial, mais en cas d'erreur il faudrat certainement
changer dans tous les formulaires. Pour 9 ca ira, mais ca va augmenter
rapidement.
Le *vrai* problème c'est de savoir si ce genre de constructions automatiques a un sens ou pas. Et pour moi il n'en a pas. Par exemple, qu'est-ce qui va se passer s'il manque une variable ? Et le jour où on a besoin d'ajouter un champ hidden dans le formulaire ? Ou si on ajoute un champ NULLable dans la table, ou un timestamp de modification/insertion qui prendra typiquement l'heure système comme valeur ? Ca va être un beau bordel. Et je ne parle même pas d'écrire du SQL correct (i.e. les numériques ne sont *PAS* entre ', et actuellement ça m'étonnerait que ça marche pour insérer des strings, manque des ' autour des champs string SQL).
Bonjour,
Merci pour votre intervention, je me pose des questions en effet.
Mon idée de départ est que j'ai 9 formulaire a mettre à jour, alors je me suis dit autant faire une fonction qui mouline et injecte dans la base de donnée, bien sur en prenant le soin de verifier avant l'insert. Il est vrai que le CRUD est teriblement compliqué à mettre en oeuvre(enfin pour moi)
Dans le cas présent, je pense que si le formulaire contient un champs hidden, il sera aussi inseré.
Donc un bon vieil INSERT codé 'en dur' en ayant auparavant fait tout le nécessaire de filtrage de variables c'est une idée "plus simple".
C'est assez trivial, mais en cas d'erreur il faudrat certainement changer dans tous les formulaires. Pour 9 ca ira, mais ca va augmenter rapidement.
John GALLET
Il est vrai que le CRUD est teriblement compliqué à mettre en oeuvre(enfin pour moi)
1) si cette méthode vous cause plus de mots de tête qu'elle ne vous résoud de problèmes, changez en.
2) je doute fort qu'une quelconque méthode de développement, CRUD ou une autre, conseille de construire à la volée les requêtes SQL en balayant bestialement les données reçues sans même se demander à quelles informations fonctionnelles elles peuvent bien correspondre. Si d'aventure vous lisiez ce genre d'abberation, changez vite de crêmerie.
A l'inverse, on peut en revanche lire le schéma de données des tables (ou tout descripteur à un quelconque format, xml pour faire hype si on veut) pour en extraire une liste de variables obligatoires et facultatives, et rechercher ces variables parmi les données reçues. Exemple de fonctionnement de ce genre : phpMyAdmin qui travaille sur n'importe quelle table. Mais attention, c'est bien une logique TOTALEMENT INVERSE de ce que vous êtes en train de faire.
Dans le cas présent, je pense que si le formulaire contient un champs hidden, il sera aussi inseré. Ce qui est loin d'être ce que vous voulez.
C'est assez trivial, mais en cas d'erreur il faudrat certainement changer dans tous les formulaires. Oui et ?
Vous pouvez le tourner comme vous voulez : sur chaque écran de saisie de données, si vous avez besoin d'autoriser à la fois l'ajout, la modification, la consultation et la suppression, il faudra coder 4 requêtes SQL. Eh oui, l'informatique c'est chiant et le métier de développeur, c'est pas rigolo tous les jours, il faudrait que certains "décideurs" s'en rendent compte.
a++; JG
Il est vrai que le CRUD est teriblement compliqué à mettre
en oeuvre(enfin pour moi)
1) si cette méthode vous cause plus de mots de tête qu'elle ne vous résoud
de problèmes, changez en.
2) je doute fort qu'une quelconque méthode de développement, CRUD ou une
autre, conseille de construire à la volée les requêtes SQL en balayant
bestialement les données reçues sans même se demander à quelles
informations fonctionnelles elles peuvent bien correspondre. Si
d'aventure vous lisiez ce genre d'abberation, changez vite de crêmerie.
A l'inverse, on peut en revanche lire le schéma de données des tables
(ou tout descripteur à un quelconque format, xml pour faire hype si on
veut) pour en extraire une liste de variables obligatoires et
facultatives, et rechercher ces variables parmi les données reçues.
Exemple de fonctionnement de ce genre : phpMyAdmin qui travaille sur
n'importe quelle table. Mais attention, c'est bien une logique TOTALEMENT
INVERSE de ce que vous êtes en train de faire.
Dans le cas présent, je pense que si le formulaire contient un champs
hidden, il sera aussi inseré.
Ce qui est loin d'être ce que vous voulez.
C'est assez trivial, mais en cas d'erreur il faudrat certainement
changer dans tous les formulaires.
Oui et ?
Vous pouvez le tourner comme vous voulez : sur chaque écran de saisie de
données, si vous avez besoin d'autoriser à la fois l'ajout, la
modification, la consultation et la suppression, il faudra coder 4
requêtes SQL. Eh oui, l'informatique c'est chiant et le métier de
développeur, c'est pas rigolo tous les jours, il faudrait que certains
"décideurs" s'en rendent compte.
Il est vrai que le CRUD est teriblement compliqué à mettre en oeuvre(enfin pour moi)
1) si cette méthode vous cause plus de mots de tête qu'elle ne vous résoud de problèmes, changez en.
2) je doute fort qu'une quelconque méthode de développement, CRUD ou une autre, conseille de construire à la volée les requêtes SQL en balayant bestialement les données reçues sans même se demander à quelles informations fonctionnelles elles peuvent bien correspondre. Si d'aventure vous lisiez ce genre d'abberation, changez vite de crêmerie.
A l'inverse, on peut en revanche lire le schéma de données des tables (ou tout descripteur à un quelconque format, xml pour faire hype si on veut) pour en extraire une liste de variables obligatoires et facultatives, et rechercher ces variables parmi les données reçues. Exemple de fonctionnement de ce genre : phpMyAdmin qui travaille sur n'importe quelle table. Mais attention, c'est bien une logique TOTALEMENT INVERSE de ce que vous êtes en train de faire.
Dans le cas présent, je pense que si le formulaire contient un champs hidden, il sera aussi inseré. Ce qui est loin d'être ce que vous voulez.
C'est assez trivial, mais en cas d'erreur il faudrat certainement changer dans tous les formulaires. Oui et ?
Vous pouvez le tourner comme vous voulez : sur chaque écran de saisie de données, si vous avez besoin d'autoriser à la fois l'ajout, la modification, la consultation et la suppression, il faudra coder 4 requêtes SQL. Eh oui, l'informatique c'est chiant et le métier de développeur, c'est pas rigolo tous les jours, il faudrait que certains "décideurs" s'en rendent compte.
