Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

JQuery --> getJSON() - Taille maximum du JSON ?

25 réponses
Avatar
Groquik
Hello !

Je viens de constater un problème plutôt embarrassant :
J'utilise la méthode getJSON() de JQuery, qui fonctionne bien... sauf
quand le JSON retourné est trop gros !

En effet, dès que les données retournées atteignent un certain nombre de
Ko, je vois correctement la réponse dans Firebug (en-tête "Réponse"),
correctement formaté en JSON, mais ma fonction de callback n'est pas
appelée :-(

En revanche, tout se passe à merveille quand la réponse est plus petite.
J'ai cherché mon problème sur plein de forums, mais sans trouver mon
problème.

Quelqu'un peut-il m'apporter ses lumières ?

Merci par avance ;-)
@++

Groquik

5 réponses

1 2 3
Avatar
Pascal
Olivier Miakinen a écrit :
Oui, peu importe le type des éléments puisque ce qui m'intéressai t ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aus si
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.



Bonjour Olivier,

Désolé, mais ça ne me parait pas si simple.

Si les deux types de tableaux étaient traités de manière identique, on
aurait le comportement suivant :

1. La propriété "length" serait disponible dans les deux cas.
2. Ajouter une propriété à un tableau indexé augmenterait sa tail le,
même si la propriété en question n'est pas un indice entier.
3. Mélanger des clés indicées et littérales pour un même tablea u
obligerait, soit à considérer un type mixte (comme en PHP), soit à
fusionner l'ensemble dans le type associatif.

Or, ce n'est pas le cas.

Déjà, les deux types ne se créent pas de la même manière, on es t bien
d'accord. Soit, littéralement, [val1, val2, ..., valN] pour l'indexé et
{prop1: val1, prop2: val2, ..., propN: valN} pour l'associatif.

Certes, JS renverra pour les deux tableaux une valeur "object" avec
l'instruction "typeof". Mais c'est aussi vrai pour une chaîne ou un
nombre s'ils sont créés avec les constructeurs "String" et "Number".

Je me suis pris la tête avec Douglas Crockford à ce sujet, et David
Flanagan l'a bien confirmé : JS offre des objets englobants, qui peuven t
même être temporaires, et qu'il faut distinguer des types primitifs.
C'est d'ailleurs pour cette raison que Douglas recommande de ne pas
utiliser les constructeurs natifs pour initialiser les variables.

Donc, pour en revenir à nos tableaux, le fait d'ajouter une propriété à
un tableau indexé ne le "transforme" pas en tableau associatif, sinon i l
perdrait la propriété "length" qui est héritée de son type primit if.
D'ailleurs, à propos de cette propriété, on peut noter qu'elle n'es t pas
énumérée dans la boucle "for ... in" appliquée à un tableau ind exé,
contrairement aux propriétés ajoutées dans le script.

Mais, pour ma part, je ne tenterais pas d'ajouter une "propriété" - a u
sens de membre d'un objet - à un tableau indexé, même si JS le perm et.
Car je crois que le type associatif, qui est le type objet primitif de
JS, me parait plus adapté pour cela, non ? Et puis quelle en serait la
véritable utilité ?

En fait, si on voulait être très précis sur le sujet, je crois qu'i l
faudrait rentrer dans l'implémentation de JS, ce qui est a priori en
dehors de mes compétences.

Cordialement,
Pascal

PS: je suis ouvert à continuer cette discussion hors forum pour ne pas
trop polluer [poncet DOT pascal AT gmail DOT com].
Avatar
SAM
Le 3/26/10 1:23 PM, Olivier Miakinen a écrit :
Le 26/03/2010 11:13, Bol a écrit :
Exemple rapide, Firefox, console, code :



Où trouves-tu ça dans Firefox ? C'est une extension ?



Menu : Outils / Console d'erreurs

En haut, un champ : Code
on y copie/colle :

var s="", a=new Array();a[1000];for(var v in a)
s+=v+"="+a[v]+",";alert(s);

et en haut un bouton : [Evaluer]
on y clique :-)

donne
1000,



Oui.



voilà.


Un peu comme de copier-coller en barre d'adresse :

javascript:
var s="", a=new Array();
a[1000];
for(var v in a)
s+=v+"="+a[v]+",";
alert(s);

puis touche Entree

--
sm
Avatar
Olivier Miakinen
Bonjour Pascal,

Le 26/03/2010 18:16, Pascal a écrit :

Oui, peu importe le type des éléments puisque ce qui m'intéressait ici
c'étaient les index. Je voulais montrer qu'un tableau en JavaScript
n'est qu'un objet comme un autre, avec une liste de propriétés, aussi
bien pour un tableau associatif que pour un tableau (que l'on croit)
indexé par des entiers.





Je me complète : je voulais surtout montrer qu'un tableau avec deux
éléments indicés 1000 et 2000 ne prendra pas mille fois plus de place
qu'un tableau avec deux éléments indicés 1 et 2.

Désolé, mais ça ne me parait pas si simple.

Si les deux types de tableaux étaient traités de manière identique, on
aurait le comportement suivant :
1. La propriété "length" serait disponible dans les deux cas.



Note que je n'ai pas dit que le traitement était identique, juste que le
type de stockage était le même. On voit bien que pour un tableau sont
traités de façon très particulière d'une part les indices entiers entre
0 et 2^32-1, d'autre part la valeur length.

2. Ajouter une propriété à un tableau indexé augmenterait sa taille,
même si la propriété en question n'est pas un indice entier.



Tu parles de la taille en mémoire, ou de la valeur de la propriété
length ? Ce sont deux notions assez indépendantes l'une de l'autre.
Si tu pars d'un tableau avec un seul élément indicé 1999, que tu lui
ajoutes 1000 éléments indicés 0 à 999 et que tu supprimes l'élément
indicé 1999 en positionnant length à 1000, sa taille sera considéra-
blement augmentée alors que sa valeur length sera divisée par deux.

3. Mélanger des clés indicées et littérales pour un même tableau
obligerait, soit à considérer un type mixte (comme en PHP), soit à
fusionner l'ensemble dans le type associatif.



Je ne sais plus comment c'est fait exactement en PHP, mais une chose est
sûre, c'est que les indices entiers sont vraiment différents des indices
chaînes de caractères. En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C'est donc
un type associatif, mais où un traitement particulier est fait lorsque
l'« indice » représente un entier entre 0 et 2^32-1.

Or, ce n'est pas le cas.

Déjà, les deux types ne se créent pas de la même manière, on est bien
d'accord. Soit, littéralement, [val1, val2, ..., valN] pour l'indexé et
{prop1: val1, prop2: val2, ..., propN: valN} pour l'associatif.

Certes, JS renverra pour les deux tableaux une valeur "object" avec
l'instruction "typeof". Mais c'est aussi vrai pour une chaîne ou un
nombre s'ils sont créés avec les constructeurs "String" et "Number".

Je me suis pris la tête avec Douglas Crockford à ce sujet, et David
Flanagan l'a bien confirmé : JS offre des objets englobants, qui peuvent
même être temporaires, et qu'il faut distinguer des types primitifs.
C'est d'ailleurs pour cette raison que Douglas recommande de ne pas
utiliser les constructeurs natifs pour initialiser les variables.



Euh... je n'ai pas tout suivi, là.

Donc, pour en revenir à nos tableaux, le fait d'ajouter une propriété à
un tableau indexé ne le "transforme" pas en tableau associatif, sinon il
perdrait la propriété "length" qui est héritée de son type primitif.



Oui, je suis parfaitement d'accord avec ça. Si tu as cru que je
prétendais le contraire, j'en suis désolé, c'est certainement que je
n'étais pas clair.

D'ailleurs, à propos de cette propriété, on peut noter qu'elle n'est pas
énumérée dans la boucle "for ... in" appliquée à un tableau indexé,
contrairement aux propriétés ajoutées dans le script.



C'est exact. Je suppose que c'est parce que cette propriété est dans le
prototype de l'objet plutôt que copiée dans l'objet lui-même ? À vrai
dire je n'en sais rien : il y a encore énormément de choses qui me
restent mystérieuses dans JavaScript.

Mais, pour ma part, je ne tenterais pas d'ajouter une "propriété" - au
sens de membre d'un objet - à un tableau indexé, même si JS le permet.
Car je crois que le type associatif, qui est le type objet primitif de
JS, me parait plus adapté pour cela, non ? Et puis quelle en serait la
véritable utilité ?



Je suis d'accord aussi. Encore une fois mon propos était juste de tenter
d'expliquer le fonctionnement interne des tableaux, lequel utilise
grosso modo le même principe nom/valeur que les autres objets plutôt que
d'avoir besoin d'un type de tableau « à la C » qui nécessite une zone
d'au moins N+1 blocs contigus pour pouvoir utiliser l'indice N.

[...]

PS: je suis ouvert à continuer cette discussion hors forum pour ne pas
trop polluer [...]



Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)


--
Olivier Miakinen
Avatar
Pascal
Olivier Miakinen a écrit :
Je me complète : je voulais surtout montrer qu'un tableau avec deux
éléments indicés 1000 et 2000 ne prendra pas mille fois plus de p lace
qu'un tableau avec deux éléments indicés 1 et 2.



Je suis d'accord, il n'y a pas d'incidence mémoire, pas plus qu'il n'y a
d'éléments "vides" créés dans les trous d'indices.

Note que je n'ai pas dit que le traitement était identique, juste que le
type de stockage était le même. On voit bien que pour un tableau so nt
traités de façon très particulière d'une part les indices entie rs entre
0 et 2^32-1, d'autre part la valeur length.



Et c'est là qu'est la particularité du langage, car il semblerait bie n
que le stockage aussi soit différent (voir plus bas).

2. Ajouter une propriété à un tableau indexé augmenterait sa t aille,
même si la propriété en question n'est pas un indice entier.



Tu parles de la taille en mémoire, ou de la valeur de la propriété
length ?



Là je faisais référence à la propriété "length".

Ce sont deux notions assez indépendantes l'une de l'autre.



Oui et non. Dans les cas d'école que tu présentes ces notions devienn ent
indépendantes. Mais tu seras sans doute d'accord pour admettre qu'un
usage normalisé du type indexé ne fera pas apparaître de différen ce.
Par "normalisé", j'entends une indexation qui commence à zéro et sa ns
trous, et aucune propriété ajoutée par le script.

[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C' est donc
un type associatif, mais où un traitement particulier est fait lorsqu e
l'« indice » représente un entier entre 0 et 2^32-1.



Pour moi, c'est là où ça ne colle pas.
Je pense au contraire qu'un tableau indexé sous JS stocke les indices
sous formes entière, alors qu'un tableau associatif stocke les clés s ous
formes de chaînes pointant vers les propriétés correspondantes (cà d une
zone mémoire où sont stockées leurs valeurs respectives).

JS gère tout son dynamisme (typage, dimensionnement, prototypage) par u n
système complexe de références. D'où ma citation approximative de s
propos de Flanagan et la notion d'objet englobants.

En (presque) clair, bien que les indices soient entiers (*), on peut y
faire référence avec une valeur chaîne comme pour n'importe quelle
propriété d'objet.
[* ce qui explique d'ailleurs qu'ils restent distincts des propriétés
ajoutées, sans quoi celles-ci compteraient dans la valeur "length" du
tableau]
Mais cela n'est valable que lorsque le tableau est référencé lui-mê me
comme un objet : le simple fait d'écrire "tableauIndexé.propriété " ou
"tableauIndexé['indiceChaîne']" suffit à appeler cette référenc e.
C'est une forme de transtypage dynamique, si l'on veut.

Le même phénomène se produit dans un cas que j'ai déjà abordé sur ce
forum à propos des chaînes et des nombres.
Lorsqu'on écrit "var maChaîne = 'test';", on stocke bien une valeur dans
une variable de type primitif chaîne.
Pourtant, lorsqu'on appelle par exemple la méthode "toUpperCase()" avec
cette variable, on pourrait croire qu'elle a été transtypée en obje t.
En fait, il semblerait (si j'ai bien compris) qu'au moment de l'appel de
la méthode, une référence soit faite à l'objet englobant du type, soit
"String" dans ce cas précis.
Celui-ci prend la valeur de la variable, lui applique la méthode et
retourne le résultat, soit la valeur en majuscules dans ce cas, au
pointeur temporaire qui en a fait l'appel.

Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]





Tu comprends maintenant pourquoi, hein ? ;-)

Euh... je n'ai pas tout suivi, là.



Peut-être que moi non plus, justement... :-|

[...] Je suppose que c'est parce que cette propriété est dans le
prototype de l'objet plutôt que copiée dans l'objet lui-même ? [. ..]



Ben voilà, c'est un peu ça l'idée.
Un bordel organisé de références entre variables, pointeurs et obje ts
englobants (traduction personnelle de ce que Flanagan appelle "wrapper
objects").

Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)



Non, bien sûr, mais on s'éloignait pas mal du fil de départ, alors je me
suis senti tout plein de scrupules ! ;-)

Cordialement,
Pascal
Avatar
Olivier Miakinen
Le 28/03/2010 21:07, Pascal a écrit :

[...]

Là je faisais référence à la propriété "length".
[...] Mais tu seras sans doute d'accord pour admettre qu'un
usage normalisé du type indexé ne fera pas apparaître de différence.
Par "normalisé", j'entends une indexation qui commence à zéro et sans
trous, et aucune propriété ajoutée par le script.



Oui, je suis d'accord. C'est ce qui est très fort : arriver à nous faire
croire (quand on ne s'écarte pas trop de l'usage « normalisé ») qu'il
s'agit d'un tableau /à la C/ alors qu'il est implémenté selon le même
modèle que les autres objets.

[...] En JavaScript, au contraire, les entiers sont
transformés en chaînes pour en faire des noms de propriétés. C'est donc
un type associatif, mais où un traitement particulier est fait lorsque
l'« indice » représente un entier entre 0 et 2^32-1.



Pour moi, c'est là où ça ne colle pas.
Je pense au contraire qu'un tableau indexé sous JS stocke les indices
sous formes entière, alors qu'un tableau associatif stocke les clés sous
formes de chaînes pointant vers les propriétés correspondantes (càd une
zone mémoire où sont stockées leurs valeurs respectives).



Eh non, il est certain que les indices sont stockés sous forme de
chaînes de caractères, comme on peut s'en convaincre d'après l'extrait
de la norme que j'avais déjà cité (paragraphe 15.4.5.1).

On y lit tout d'abord que la méthode [[Put]] des objets Array est une
variation de celle utilisée pour les autres objets ECMAScript natifs
(dans laquelle le paramètre P est toujours une string). Juste en dessous
ils redisent que P est une string. Un peu plus loin on voit qu'ils font
un ToUint32(P) pour pouvoir le comparer avec la valeur de length. Enfin,
argument imparable, les propriétés détruites quand on change length et
qu'un entier k devient plus grand que length sont celles qui sont
nommées ToString(k) !

Pour mémoire, je recopie l'extrait en question :
----------------------------------------------------------------------
15.4.5.1 [[Put]] (P, V)
Array objects use a variation of the [[Put]] method used for other native ECMAScript objects
(8.6.2.2).
Assume A is an Array object and P is a string.
When the [[Put]] method of A is called with property P and value V, the following steps are taken:
1. Call the [[CanPut]] method of A with name P.
2. If Result(1) is false, return.
3. If A doesn’t have a property with name P, go to step 7.
4. If P is "length", go to step 12.
5. Set the value of property P of A to V.
6. Go to step 8.
7. Create a property with name P, set its value to V and give it empty attributes.
8. If P is not an array index, return.
9. If ToUint32(P) is less than the value of the length property of A, then return.
10. Change (or set) the value of the length property of A to ToUint32(P)+1.
11. Return.
12. Compute ToUint32(V).
13. If Result(12) is not equal to ToNumber(V), throw a RangeError exception.
14. For every integer k that is less than the value of the length property of A but not less than
Result(12), if A itself has a property (not an inherited property) named ToString(k), then delete
that property.
15. Set the value of property P of A to Result(12).
16. Return.


----------------------------------------------------------------------

[...]

Je me suis pris la tête avec Douglas Crockford à ce sujet, [...]





Tu comprends maintenant pourquoi, hein ? ;-)



Je comprends maintenant que tu parlais de la différence entre une
valeur de type string et une valeur de type String. En effet cette
distinction existe bien en JavaScript, même si des transtypages
implicites la masquent souvent.

Je n'ai pas l'impression que parler du fonctionnement interne de
JavaScript pollue un groupe spécifiquement consacré aux langages de
script tels que JavaScript... si ? ;-)



Non, bien sûr, mais on s'éloignait pas mal du fil de départ, alors je me
suis senti tout plein de scrupules ! ;-)



Pas de problème à mon avis, puisque j'avais changé le titre.

Cordialement,
--
Olivier Miakinen
1 2 3