Bonjour
comment faire pour envoyer le tableau suivant
$Var=array( "var2","var3","var4","var5"), avec la methode GET
j'ai deja utiliser la methode serialize et unserialize mais ca marche pas a cause de ""
y'a t'elle une autre solution
et merci pour votre aide

Je ne sais pas ce que tu as essayé, mais les fonctions serialize() et unserialize() fonctionnent très bien sur n'importe quel type de tableau, qu'il contienne des nombres, des chaines, des guillemets, des objets, etc.
Et encore heureux parce que c'est justement à cela qu'elle servent

Peut être que lire la documentation des fonctions que tu utilises t'aiderait à comprendre à quoi elles servent et comment les utiliser ?

Je mettrais juste un bemol sur le serialize des objets a partir de php5 car quand il y a des attributs ou des fonctions protected ou private, serialize() utilise un caractère \000 qui peut parfois poser des problèmes.
Pour stocker en base par exemple, pour beaucoup de système, le 0 a la signification de fin de chaîne, et quand tu passes par une API type OCI, et bien je n'ai pas encore trouvé de solutions si ce n'est d'encoder le résultat du serialize en base64.

Dans le cas d'un simple tableau tel que l'exemple donné, effectivement, il n'y a aucun pb pour le passer via get.

et mysql_real_escape_string()?

en l'occurrence, j'evoque OCI et donc oracle, pas mysql... mais j'ai bien entendu essayé l'équivalent mais sans succès.

Et quel est l'intérêt de stocker un objet en BdD ?

On perd l'indépendance donnée/traitement dans ce cas de figure ... :S

beuh... je rappelle tout de même que la question de départ c'est passer un tableau en GET, pas sérialiser un objet pour le mettre en base

Ryle: La question de départ à eu sa réponse mais a soulevée une digression vers le sérialize qui n'est pas forcement inintéressante.

Dans mon cas, l'intérêt est de pouvoir stocker un agrégat de données représentant une seule donnée. L'agrégat étant évolutif sans pour autant avoir d'impact sur le schéma de la base. Les évolutions de schemas étant toujours assez complexe en prod surtout quand on est sur du 24/24 et que l'on veux pouvoir gérer le retour arrière sur tel ou tel évolution.

La contrainte est qu'il ne faut pas avoir besoin de faire des requêtes sql sur cet objet. Sur un objet complexe, cela limite le nombre de colonne aussi qui peut devenir pénible a gérer/lire si une table doit gérer plusieurs objets complexe.

Pardon Mr Ryle, mais j'ai l'impression que l'auteur n'est toujours pas revenu ...

Sinon, pour répondre à titerm, je suis partisan du fait qu'une structure de données qui représente les données qu'elle contient permet toute modification sur ces données ...
Mais bon ... j'espère pour toi que tu ne te retrouveras jamais dans un cas où tu te diras que j'avais raison

Zeus, quand on stock une image dans un blob, on ne stock pas l'éditeur avec. A la relecture, on est censé soit savoir l'afficher, soit savoir la modifier.
Et quand je stock une version sérializé d'un objet, c'est pareil, je suis censé avoir la classe dont il est issu. Mais rien n'empêche aller un poil plus loin et de stocker le source de la classe au sein d'un meta objet.
Mais je trouve cela superflu. Le jours où je n'ai plus la classe pour exploiter les données, cela signifie aussi que le site est HS...

Une image stockée dans une base de données à un sens puisqu'elle est en relation avec la données.
Cette image est stockée en binaire et tout langage est capable de lire du binaire pour reconstruire l'image originelle, soit directement, soit via des couches additionnelles.

Alors que sérializer un objet d'un langage en base de données, c'est imposer la lecture de la base de données avec le même langage. Je doute fort que PHP et Java sérialize leurs objets de la même manière
Comme je te le disais précédemment, dans 80% des projets, on ne change pas le langage ... mais il reste 20% ...

L'algorithme serialize de php est connu et il existe des unserialize dans d'autre langage. J'en ai même codé un en javascript a l'époque ou JSON n'était qu'une extension PECL non intégré au core PHP.
C'est plutôt trivial à faire.
J'aurai pu utiliser JSON mais json_encode ne vois pas pas les propriété privé et protected.
Il serait aussi possible faire un proxy de conversion JSON/Serialize mais encore une fois, je n'en vois pas l'intérêt. Les données qui sont stockées en base sont les données qui font vivre le site et n'ont pas vocation à être conserver ad vitam eternam. Le jour où on changera de langage, il y aura forcement une nouvelle charte graphique avec et des nouvelles maquettes. Et donc de nouvelles données.

euh ... je fait évoluer les interfaces de tous les projets sur lesquels j'interviens et je ne change pas le modèle de données à chaque fois ...

De plus, l'indépendance de la donnée face à la présentation me semble extremement importante ...
Selon ma vision de la base de données, je n'ai rien à modifier en base de données si je change la présentation de ces données ...

Mais bon, je pense que personne n'arrivera à convaincre l'autre

De plus, l'indépendance de la donnée face à la présentation me semble extremement importante ...
Selon ma vision de la base de données, je n'ai rien à modifier en base de données si je change la présentation de ces données ...

Mais bon, je pense que personne n'arrivera à convaincre l'autre

En effet zeus, tu défends une vision théorique idéale qui peut parfois être source d'un gros casse-tête, en particulier quand tu te retrouves avec un nouveau besoin en milieu de projet, que ta base est déjà faite et que tu ne souhaites pas trop la retoucher.

Je me suis retrouvé devant le même choix que titerm et j'ai dû, à contrecoeur, opter comme lui. Après étude, le projet sur lequel je travaillais (et surtout l'agrégat de données en question) n'avait pas vocation à être attaqué dans un autre langage et de plus l'agrégat n'était que très peu factorisable et censé être évolutif. Un genre de fourre-tout, quoi. Stocker des structures sérialisées était une solution à la fois souple et rapide à mettre en oeuvre plutôt qu'une modif lourde de la base de données et des procédures métier pour la manipuler qui allaient avec.

Conclusion : les specs qui changent en milieu ou en fin de projet, c'est très très mal

Ce que je veux dire c'est que ce sont des données administrés par le webmaster. Elle n'ont une durée de vie qu'un temps extrêmement court. Par exemple, ca va etre une image et tout ce qui la compose (le alt, le onclick etc...), ou dans le cas d'un lien ce sera l'url, le label, les events, etc...).

Maintenant comme tu le dis, personne ne convaincra l'autre. Pour une raison simple, c'est que tu ne voie que la méthode et que tu ne voie pas le contexte. Je suis dans une grosse boite, une modif de schémas, c'est une galère a gérer, trop de monde impliqué, du coup, ca prend enormément de temps, d'énergie, etc... Le marketing change d'avis tous le temps et du coup le contenu aussi. Cette solution est pour nous un moyen simple de pouvoir répondre rapidement a des demandes ésotérique sans remettre en cause en permanence l'existant.