J'aimerais récupérer tous les mots contenus dans une phrase par un
list() = explode(' ', $maphrase) en ne sachant pas à l'avance le
nombre de mots que contient cette phrase, donc je ne peux pas définir
les noms de mes variables récupérées par list().
Un exemple pour être plus claire (je sais bien que tout ceci peut vous
sembler confus).
Soit :
$maphrase = "vert jaune bleu";
Dans ce cas je sais qu'il y a 3 valeurs et je peux les récupérer de la
manière suivante :
list($couleur1,$couleur2,$couleur3) = explode(' ', $maphrase);
Mais lorsqu'on ne sait pas à l'avance combien de valeurs contient
$maphrase ?
Ca me paraissait tellement simple mais rien à faire ! bon, je suis un
peu débutante aussi, alors ceci explique peut être cela ;)
Le 25 May 2004 11:15:35 GMT, John Gallet écrivait:
Je n'en suis pas certain. En fait je n'ai pas le temps de m'amuser à regarder la RFC "kivabien" mais je ne garantis vraiment pas que l'utilisation de N variables qui ont toutes le même nom, avec des [] qui plus est, est vraiment un cas prévu, documenté, et associé à un comportement officiel de la part des navigateurs, tant en méthode GET pour les liens http qu'en méthode Post.
Oupss John faut pas faire une fixation sur les FORM :-)... le contexte de la question originale portait uniquement sur une séquence interne de script, qui il me semble portait juste sur le parse des lignes d'un fichier. Dans ce cas particulier créer des variables numérotées (créées dynamiquement en plus) n'est pas vraiment l'idéal, ne serait que pusqu'à priori on ne connait pas le nombre de variables qui vont être créees, il faut tenir un compteur, et ensuite pour réutiliser ces variable il faut à chaque fois reconstruire leur nom dynamiquement avec ce compteur comme limite haute (on ne peut pas coder leur nom en dur puisqu'on ne sait pas le nom de la dernière).
Dans ce cas de traiement "interne " du script l'utilisation d'un tableau s'impose.
Il me semble avoir souvenance d'une version d'Opéra qui n'aimait pas du tout cette notation, mais je n'en mettrai pas ma main au feu. En tous cas, les espaces dans les noms de variables, opéra n'aime pas du tout (alors que IE et même mon bon vieux netscape 4.7x acceptent).
Ca au moins c'est un cas de figure pratique qu'il est bon de lire dans NG, même s'il ne s'applique pas au contexte de la question :-).
simili-tableau, les facilités d'évolution, de manipulations (et maintenance) offerte par celui-ci en moins bien sur....
Maintenance ? Tu veux dire mise à jour ? Je ne vois pas de différence entre $tab[$i]=.... et ${'tab'.$i}=... en facilité de mise à jour, mais j'ai peut-êter compris de travers.
Je parlais de maintenance dans le sens qu'il est plus facile de reprendre un algo qui traite via un foreach par exemple, un tableau genre :
foreach ($tab_couleur as $value) { echo "Valeur: $value<br>n"; } q'un algo ou chaque variables doivent être traitée une par une :
C'est une source d'erreur, t'a vite fait de te gourer dans le nom de la variable et comme php n'est pas déclaratif, ca ne génére pas une erreur, par exemple si tu as mis par erreur comme je l'ai fait sans le faire exprès $tal_couleur2 au lieu de tab_couleur2. Avec le tableau tu n'as pas ce genre de problème.
Maintenant c'est vrai que que pour 3 ou 4 valeur pour une variable c'est pas trop gênant (du moins si t'es sur qu'à l'avenir tu n'auras pas à en rajouter).
Bien plus pratique ? A part si on a besoin des fonctions disponibles sur les tableaux, je ne vois pas en quoi. Et je me vois mal faire un array_sort sur des choix dans un formulaire !
Ben moi j'ai déjà eu le cas :-)) Dans une appli locale qui reçoit une liste de fichiers en paramètre dans un tableau via un formulaire justement...
Le 25 May 2004 11:15:35 GMT, John Gallet <john.gallet@wanadoo.fr> écrivait:
Je n'en suis pas certain. En fait je n'ai pas le temps de m'amuser à
regarder la RFC "kivabien" mais je ne garantis vraiment pas que
l'utilisation de N variables qui ont toutes le même nom, avec des [] qui
plus est, est vraiment un cas prévu, documenté, et associé à un
comportement officiel de la part des navigateurs, tant en méthode GET
pour les liens http qu'en méthode Post.
Oupss John faut pas faire une fixation sur les FORM :-)... le contexte de la
question originale portait uniquement sur une séquence interne de script,
qui il me semble portait juste sur le parse des lignes d'un fichier. Dans ce
cas particulier créer des variables numérotées (créées dynamiquement en
plus) n'est pas vraiment l'idéal, ne serait que pusqu'à priori on ne connait
pas le nombre de variables qui vont être créees, il faut tenir un compteur,
et ensuite pour réutiliser ces variable il faut à chaque fois reconstruire
leur nom dynamiquement avec ce compteur comme limite haute (on ne peut pas
coder leur nom en dur puisqu'on ne sait pas le nom de la dernière).
Dans ce cas de traiement "interne " du script l'utilisation d'un tableau
s'impose.
Il me semble avoir souvenance d'une version d'Opéra qui n'aimait pas du
tout cette notation, mais je n'en mettrai pas ma main au feu. En tous
cas, les espaces dans les noms de variables, opéra n'aime pas du tout
(alors que IE et même mon bon vieux netscape 4.7x acceptent).
Ca au moins c'est un cas de figure pratique qu'il est bon de lire dans NG,
même s'il ne s'applique pas au contexte de la question :-).
simili-tableau, les facilités d'évolution, de manipulations (et
maintenance) offerte par celui-ci en moins bien sur....
Maintenance ? Tu veux dire mise à jour ? Je ne vois pas de différence
entre $tab[$i]=.... et ${'tab'.$i}=... en facilité de mise à jour, mais
j'ai peut-êter compris de travers.
Je parlais de maintenance dans le sens qu'il est plus facile de reprendre
un algo qui traite via un foreach par exemple, un tableau genre :
foreach ($tab_couleur as $value) {
echo "Valeur: $value<br>n";
}
q'un algo ou chaque variables doivent être traitée une par une :
C'est une source d'erreur, t'a vite fait de te gourer dans le nom de la
variable et comme php n'est pas déclaratif, ca ne génére pas une erreur, par
exemple si tu as mis par erreur comme je l'ai fait sans le faire exprès
$tal_couleur2 au lieu de tab_couleur2. Avec le tableau tu n'as pas ce genre
de problème.
Maintenant c'est vrai que que pour 3 ou 4 valeur pour une variable c'est pas
trop gênant (du moins si t'es sur qu'à l'avenir tu n'auras pas à en
rajouter).
Bien plus pratique ? A part si on a besoin des fonctions disponibles sur
les tableaux, je ne vois pas en quoi. Et je me vois mal faire un
array_sort sur des choix dans un formulaire !
Ben moi j'ai déjà eu le cas :-)) Dans une appli locale qui reçoit une liste
de fichiers en paramètre dans un tableau via un formulaire justement...
Le 25 May 2004 11:15:35 GMT, John Gallet écrivait:
Je n'en suis pas certain. En fait je n'ai pas le temps de m'amuser à regarder la RFC "kivabien" mais je ne garantis vraiment pas que l'utilisation de N variables qui ont toutes le même nom, avec des [] qui plus est, est vraiment un cas prévu, documenté, et associé à un comportement officiel de la part des navigateurs, tant en méthode GET pour les liens http qu'en méthode Post.
Oupss John faut pas faire une fixation sur les FORM :-)... le contexte de la question originale portait uniquement sur une séquence interne de script, qui il me semble portait juste sur le parse des lignes d'un fichier. Dans ce cas particulier créer des variables numérotées (créées dynamiquement en plus) n'est pas vraiment l'idéal, ne serait que pusqu'à priori on ne connait pas le nombre de variables qui vont être créees, il faut tenir un compteur, et ensuite pour réutiliser ces variable il faut à chaque fois reconstruire leur nom dynamiquement avec ce compteur comme limite haute (on ne peut pas coder leur nom en dur puisqu'on ne sait pas le nom de la dernière).
Dans ce cas de traiement "interne " du script l'utilisation d'un tableau s'impose.
Il me semble avoir souvenance d'une version d'Opéra qui n'aimait pas du tout cette notation, mais je n'en mettrai pas ma main au feu. En tous cas, les espaces dans les noms de variables, opéra n'aime pas du tout (alors que IE et même mon bon vieux netscape 4.7x acceptent).
Ca au moins c'est un cas de figure pratique qu'il est bon de lire dans NG, même s'il ne s'applique pas au contexte de la question :-).
simili-tableau, les facilités d'évolution, de manipulations (et maintenance) offerte par celui-ci en moins bien sur....
Maintenance ? Tu veux dire mise à jour ? Je ne vois pas de différence entre $tab[$i]=.... et ${'tab'.$i}=... en facilité de mise à jour, mais j'ai peut-êter compris de travers.
Je parlais de maintenance dans le sens qu'il est plus facile de reprendre un algo qui traite via un foreach par exemple, un tableau genre :
foreach ($tab_couleur as $value) { echo "Valeur: $value<br>n"; } q'un algo ou chaque variables doivent être traitée une par une :
C'est une source d'erreur, t'a vite fait de te gourer dans le nom de la variable et comme php n'est pas déclaratif, ca ne génére pas une erreur, par exemple si tu as mis par erreur comme je l'ai fait sans le faire exprès $tal_couleur2 au lieu de tab_couleur2. Avec le tableau tu n'as pas ce genre de problème.
Maintenant c'est vrai que que pour 3 ou 4 valeur pour une variable c'est pas trop gênant (du moins si t'es sur qu'à l'avenir tu n'auras pas à en rajouter).
Bien plus pratique ? A part si on a besoin des fonctions disponibles sur les tableaux, je ne vois pas en quoi. Et je me vois mal faire un array_sort sur des choix dans un formulaire !
Ben moi j'ai déjà eu le cas :-)) Dans une appli locale qui reçoit une liste de fichiers en paramètre dans un tableau via un formulaire justement...
Le 25 May 2004 11:15:35 GMT, Olivier Miakinen <om+ écrivait:
Tout-à-fait d'accord. La meilleure réponse a d'ailleurs été donnée par Antoine Dinimant, qui comme les autres a expliqué que le tableau était préférable, puis a expliqué comment faire des variables variables tout en rappelant que cela n'avait que des inconvénients.
Oui effectivement ce post (qui n'était pas encore arrivé sur mon serveur de NG quand j'ai répondu) synthétise parfaitement ce fil.
Le 25 May 2004 11:15:35 GMT, Olivier Miakinen <om+news@miakinen.net>
écrivait:
Tout-à-fait d'accord. La meilleure réponse a d'ailleurs été donnée par
Antoine Dinimant, qui comme les autres a expliqué que le tableau était
préférable, puis a expliqué comment faire des variables variables tout
en rappelant que cela n'avait que des inconvénients.
Oui effectivement ce post (qui n'était pas encore arrivé sur mon serveur de
NG quand j'ai répondu) synthétise parfaitement ce fil.
Le 25 May 2004 11:15:35 GMT, Olivier Miakinen <om+ écrivait:
Tout-à-fait d'accord. La meilleure réponse a d'ailleurs été donnée par Antoine Dinimant, qui comme les autres a expliqué que le tableau était préférable, puis a expliqué comment faire des variables variables tout en rappelant que cela n'avait que des inconvénients.
Oui effectivement ce post (qui n'était pas encore arrivé sur mon serveur de NG quand j'ai répondu) synthétise parfaitement ce fil.
euh, nous parlions de variables PHP et non de formulaires HTML...
Euh, "j'avais compris" (dit-il d'extrêmement mauvaise foi, ayant lu le troll sur _GET/_POST juste avant de répondre je me suis emmêlé les crayons. Aïe non pas la tête !).
On va le dire comme ça : je rappelais que l'une des applications possibles de la construction de variables dynamiques est le traitement des formulaires de type "watt-milliard de cases à cocher" ou upload de plusieurs fichiers où là elles peuvent être pratiques (là ce n'est pas de la mauvaise foi).
En revanche, je n'ai jamais eu à gérer (en PHP) de cas où ça serve à autre chose (en shell oui). Sauf à avoir une table avec (une partie) des noms de colonne générique (data1, data2...) je ne vois pas non plus d'intérêt à utiliser cette notation par rapport à un bon vieux tableau en dehors de get/post <troll> et request bien sûr </troll>.
a++ JG
Re,
euh, nous parlions de variables PHP et non de formulaires HTML...
Euh, "j'avais compris" (dit-il d'extrêmement mauvaise foi, ayant lu le
troll sur _GET/_POST juste avant de répondre je me suis emmêlé les
crayons. Aïe non pas la tête !).
On va le dire comme ça : je rappelais que l'une des applications
possibles de la construction de variables dynamiques est le traitement
des formulaires de type "watt-milliard de cases à cocher" ou upload de
plusieurs fichiers où là elles peuvent être pratiques (là ce n'est pas
de la mauvaise foi).
En revanche, je n'ai jamais eu à gérer (en PHP) de cas où ça serve à
autre chose (en shell oui). Sauf à avoir une table avec (une partie) des
noms de colonne générique (data1, data2...) je ne vois pas non plus
d'intérêt à utiliser cette notation par rapport à un bon vieux tableau
en dehors de get/post <troll> et request bien sûr </troll>.
euh, nous parlions de variables PHP et non de formulaires HTML...
Euh, "j'avais compris" (dit-il d'extrêmement mauvaise foi, ayant lu le troll sur _GET/_POST juste avant de répondre je me suis emmêlé les crayons. Aïe non pas la tête !).
On va le dire comme ça : je rappelais que l'une des applications possibles de la construction de variables dynamiques est le traitement des formulaires de type "watt-milliard de cases à cocher" ou upload de plusieurs fichiers où là elles peuvent être pratiques (là ce n'est pas de la mauvaise foi).
En revanche, je n'ai jamais eu à gérer (en PHP) de cas où ça serve à autre chose (en shell oui). Sauf à avoir une table avec (une partie) des noms de colonne générique (data1, data2...) je ne vois pas non plus d'intérêt à utiliser cette notation par rapport à un bon vieux tableau en dehors de get/post <troll> et request bien sûr </troll>.
a++ JG
Eric Daspet
John Gallet wrote:
Bien plus pratique ? A part si on a besoin des fonctions disponibles sur les tableaux, je ne vois pas en quoi. Et je me vois mal faire un array_sort sur des choix dans un formulaire !
Les noms en "champ[]" sont tout de même nécessaires dans un cas : les sélections multiples : <select multiple name="champ[]"> Dans ce cas précis, sauf à interpréter manuellement la chaîne de GET/POST, cette notation n'a pas d'alternative. Pratique je ne sais pas mais nécessaire oui, parfois.
-- Eric Daspet Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
John Gallet wrote:
Bien plus pratique ? A part si on a besoin des fonctions disponibles sur
les tableaux, je ne vois pas en quoi. Et je me vois mal faire un
array_sort sur des choix dans un formulaire !
Les noms en "champ[]" sont tout de même nécessaires dans un cas : les
sélections multiples : <select multiple name="champ[]">
Dans ce cas précis, sauf à interpréter manuellement la chaîne de
GET/POST, cette notation n'a pas d'alternative.
Pratique je ne sais pas mais nécessaire oui, parfois.
--
Eric Daspet
Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
Bien plus pratique ? A part si on a besoin des fonctions disponibles sur les tableaux, je ne vois pas en quoi. Et je me vois mal faire un array_sort sur des choix dans un formulaire !
Les noms en "champ[]" sont tout de même nécessaires dans un cas : les sélections multiples : <select multiple name="champ[]"> Dans ce cas précis, sauf à interpréter manuellement la chaîne de GET/POST, cette notation n'a pas d'alternative. Pratique je ne sais pas mais nécessaire oui, parfois.
-- Eric Daspet Venez aider notre mangeur de cigogne sur http://mangeur-de-cigogne.info/
angelique
(Anonyme de Webatou.net) wrote in message news:<40b1ee82$0$26917$...
Utilisateur_anonyme_et_non_membre_de_webatou.net@anonyme.com (Anonyme de Webatou.net) wrote in message news:<40b1ee82$0$26917$626a14ce@news.free.fr>...
