GLPI-PROJECT

JMD : Sur un petit array ça me semble pas gênant en revanche avec un gros array on va généner beaucoup de champs pour pas grand chose tout de même. Il faut voir aussi l'impact avec les limites de paramétrages des serveurs genre max input var etc...

J'avais oublié ce "détail". Il n'empêche que nous pouvons passer par cette méthode unique qui affiche les champs hidden. Quitte, pour le moment, à utiliser json_encode et json_decode au lieu de "splitter" en autant de champs hidden que d'éléments dans le tableau.
Cela nous permettra, si nous trouvons une meilleure solution, de basculer dans ce nouveau formalisme plus rapidement.

A-t-on un moyen de tracer le nombre total de champs dans les formulaires ?

webmyster wrote:

A-t-on un moyen de tracer le nombre total de champs dans les formulaires ?

C'est à dire ?

Avoir un ordre de grandeur du nombre de champs dans les formulaires afin de savoir si on peut envisager de passer par la solution 1 élement d'un tableau => un champs hidden.

Après reflexion, nous pourrions compter simplement le nombre d'entrée dans le champs $_POST (en incluant le nombre d'éléments dans les tableaux). Mais a-t-on une idée précise des restrictions des différents navigateurs en nombre de variables transmissibles par la methode POST ?

ce n'est pas vraiment le navigateur mais le serveur avec les max_input_vars