je me pose une question qui tue !!!
je dois afficher une centaine de ligne de 5 colonnes dans un tableau.
Je m'interesse a la vitesse d'affichage (et dont implicitement de
téléchargement)
j'ai donc essayé 4 méthodes!
- du html brute de fonderie
- du xhtml en placant le css dans un fichier a part
- la génération du tableau a base de document.write (en javascript donc)
- la génération du tableau a base de createElement, appendChild, ... (la
méthode à la mode)
et ben on s'y attendais ou on s'y attendait pas, mais si on met a part le
download, l'ordre précedent est aussi celui allant du plus rapide au plus
lent...
J'en profite pour dire que la génération a base d'objet du DOM, en non
seulement BEAUCOUP plus lente que le reste, mais en plus IE gère comme une
merde le cache, et donc pour peu qu'il y ai une image dans votre tableau, de
temps en temps IE, va decider de la redownloader autant de fois qu'il y a
des lignes !!!! (le problème n'existant pas avec mozilla)
Finalement,
Tout revient donc ce demander si on a une connexion haut débit ou bas debit.
avec l'ADSL -> HTML a donf
via un modem, le javascript tire pas mal son épingle du jeu...
Il faut egalement préciser que si votre ligne de tableau est complexe.
(genre incluant des images, ou des liens)
la vitesse de javascript va etre plus ou moins constante alors que la taille
de la page en HTML va grossir vite fait.
Et donc meme avec l'ADSL, il peut etre interessant d'opter pour le
javascript avec la bonne vieille méthode document.write.
Alors evidement, on est un peu triste, parce qu'il eu été plus beau que le
createElement fut le plus rapide. !
J'en finirai pour dire deux chose:
- Faite le minimum de docuement.write! Préférer générer un logue chaine de
caractère que vous envérez d'un coup
- Sous Mozilla, les resultats sont un peu moins violent, car mozilla rame
grave avec un document.write. Dans tout les cas il reste plus lent que IE,
mais en utilisant le CreateElement, la différence est peu sensible.
Voila.
quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas
fait une erreur quelques part????
Bon j'ai donc essayé! et c'est vrai que cela aurait pu etre une bonne solution. si biensur la decompression etait plus rapide que la génération du code HTML en javascript.
ca m'etonne quand meme
c'est vrai que dans mon explication j'avais oublié de précisé que j'utilise un celeron 700
ce qui n'est quand meme pas un veau...
et il s'avère donc, que la décompression (en tout cas sour IE) le met complètement à genou...
avec quelle version de IE ? c'est pas plutot le fait de devoir generer une table enorme d'une seule traite qui le met a genou ?
ca serait interessant de poster la source (enfin, une seule ligne de table einh ;) pour faire des tests sur d'autres configs
Ce qui est con, c'est que j'ai passé l'apres midi à remplacer ma génération Javascript en HTML parce que ca semblait tellement logique que ce soit la bonne solution que j'ai pas fait trop de tests.
ouais enfin j'avais suggere de generer la table en php et pas de tout faire a la main...
bon. ben c'est bon a savoir. finalement, la methode la plus performant (et on va dire la plus equilibrée) consiste a générer la page coté client en javascript a l'aide de document.write... cela offre un equilibre correcte entre la taille- le temps serveur - le temps client.
mais si pas de javascript, pas de table
a+
-- freelance + web design + php dev + digital photo + http://www.capsule.org
Etienne SOBOLE wrote:
ben si finalement c'etait con ;)
c'est celui qui le dit qui l'est :)
Bon j'ai donc essayé!
et c'est vrai que cela aurait pu etre une bonne solution.
si biensur la decompression etait plus rapide que la génération du code HTML
en javascript.
ca m'etonne quand meme
c'est vrai que dans mon explication j'avais oublié de précisé que j'utilise
un celeron 700
ce qui n'est quand meme pas un veau...
et il s'avère donc, que la décompression (en tout cas sour IE) le met
complètement à genou...
avec quelle version de IE ?
c'est pas plutot le fait de devoir generer une table enorme d'une seule
traite qui le met a genou ?
ca serait interessant de poster la source (enfin, une seule ligne de
table einh ;) pour faire des tests sur d'autres configs
Ce qui est con, c'est que j'ai passé l'apres midi à remplacer ma génération
Javascript en HTML parce que ca semblait tellement logique que ce soit la
bonne solution que j'ai pas fait trop de tests.
ouais enfin j'avais suggere de generer la table en php et pas de tout
faire a la main...
bon. ben c'est bon a savoir.
finalement, la methode la plus performant (et on va dire la plus equilibrée)
consiste a générer la page coté client en javascript a l'aide de
document.write... cela offre un equilibre correcte entre la taille- le temps
serveur - le temps client.
mais si pas de javascript, pas de table
a+
--
freelance + web design + php dev + digital photo
+ http://www.capsule.org
Bon j'ai donc essayé! et c'est vrai que cela aurait pu etre une bonne solution. si biensur la decompression etait plus rapide que la génération du code HTML en javascript.
ca m'etonne quand meme
c'est vrai que dans mon explication j'avais oublié de précisé que j'utilise un celeron 700
ce qui n'est quand meme pas un veau...
et il s'avère donc, que la décompression (en tout cas sour IE) le met complètement à genou...
avec quelle version de IE ? c'est pas plutot le fait de devoir generer une table enorme d'une seule traite qui le met a genou ?
ca serait interessant de poster la source (enfin, une seule ligne de table einh ;) pour faire des tests sur d'autres configs
Ce qui est con, c'est que j'ai passé l'apres midi à remplacer ma génération Javascript en HTML parce que ca semblait tellement logique que ce soit la bonne solution que j'ai pas fait trop de tests.
ouais enfin j'avais suggere de generer la table en php et pas de tout faire a la main...
bon. ben c'est bon a savoir. finalement, la methode la plus performant (et on va dire la plus equilibrée) consiste a générer la page coté client en javascript a l'aide de document.write... cela offre un equilibre correcte entre la taille- le temps serveur - le temps client.
mais si pas de javascript, pas de table
a+
-- freelance + web design + php dev + digital photo + http://www.capsule.org
Thibaut Allender a *crit :
Etienne SOBOLE wrote:
> Voila. > quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas > fait une erreur quelques part????
ben, si je dois generer un tableau et que je veux que ca soit rapide, je le fais en server-side (php,asp,cfm...)
Ça ! ça veut dire que le serveur-side n'est pas débordé ! Ça, ça veut dire qu'on a hyper léché son code. (qui le fait vraiment ?)
Je n'y connais pas grd chose en php, et je l'ai vaguement essayé chez free
==>
bon, c'est cool le php, mais qu'est ce que ça peut ramer ! ! !
et si c'est tres gros, j'active la compression gzip
???? Y en a qui balancent direct du gzip ? C'est pour ça que mon ordi plante ? (sur certain site)
l'affichage est classique (html ou xhtml), ne depend pas de l'activation du javascript chez la personne qui visite la page, et leger grace a la compression
??? et comment, par quoi, c'est décompressé ? ça passe sur toutes les configs ?
*ca* c'est une methode "a la mode" ;)
-- freelance + web design + php dev + digital photo + http://www.capsule.org
> Voila.
> quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas
> fait une erreur quelques part????
ben, si je dois generer un tableau et que je veux que ca soit rapide, je
le fais en server-side (php,asp,cfm...)
Ça !
ça veut dire que le serveur-side n'est pas débordé !
Ça,
ça veut dire qu'on a hyper léché son code.
(qui le fait vraiment ?)
Je n'y connais pas grd chose en php,
et je l'ai vaguement essayé chez free
==>
bon,
c'est cool le php,
mais qu'est ce que ça peut ramer ! ! !
et si c'est tres gros, j'active
la compression gzip
????
Y en a qui balancent direct du gzip ?
C'est pour ça que mon ordi plante ? (sur certain site)
l'affichage est classique (html ou xhtml), ne depend pas de l'activation
du javascript chez la personne qui visite la page, et leger grace a la
compression
???
et comment, par quoi, c'est décompressé ?
ça passe sur toutes les configs ?
*ca* c'est une methode "a la mode" ;)
--
freelance + web design + php dev + digital photo
+ http://www.capsule.org
> Voila. > quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas > fait une erreur quelques part????
ben, si je dois generer un tableau et que je veux que ca soit rapide, je le fais en server-side (php,asp,cfm...)
Ça ! ça veut dire que le serveur-side n'est pas débordé ! Ça, ça veut dire qu'on a hyper léché son code. (qui le fait vraiment ?)
Je n'y connais pas grd chose en php, et je l'ai vaguement essayé chez free
==>
bon, c'est cool le php, mais qu'est ce que ça peut ramer ! ! !
et si c'est tres gros, j'active la compression gzip
???? Y en a qui balancent direct du gzip ? C'est pour ça que mon ordi plante ? (sur certain site)
l'affichage est classique (html ou xhtml), ne depend pas de l'activation du javascript chez la personne qui visite la page, et leger grace a la compression
??? et comment, par quoi, c'est décompressé ? ça passe sur toutes les configs ?
*ca* c'est une methode "a la mode" ;)
-- freelance + web design + php dev + digital photo + http://www.capsule.org
Tu as envisagé de générer un tableau via javascript juste pour la vitesse ? c'est bizarre comme raisonnement.
Tout dépend ce que tu as à générer comme tableau Quand en une 12aine de lignes tu peux envoyer un calendrier à jour au lieu du même tableau qui aura besoin de tte façon du JS des dates Tu dois y gagner en temps de connexion/affichage (en tous cas en RTC c'est flagrant) Et si tu le généres en php, il faudra être bien patient que le serveur ait le temps de s'occuper de ton cas puis qu'il envoie toute la tartine
temps de calcul (aléatoire) serveur-side + temps de txfer d'un gros fichier contre txfer de mini-fichier + temps de calcul sur un ordi qui n'a que ça à faire c'est vite vu !
> J'en profite pour dire que la génération a base d'objet du DOM, en non > seulement BEAUCOUP plus lente que le reste,
Oui mais après tu peux accéder à ces éléments via le DOM, ce qui est plutôt interessant.
??? Si c'est juste pour récupérer des element.value ==> le DOM consomme plus de code et m'étonnerait que les arrays du DOM soient plus rapides à gérer Pour la création ça reste à voir
> quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas > fait une erreur quelques part????
Je vais ptet passé pour un intégriste à barbe fou du texte brut, mais générer un tableau avec JS juste pour réduire le temps de téléchargement n'est pas une bonne méthode,
??? pour ceusses adesséllés (et qui fonctionne) peut-être, mais en RTC ???
car ça pose des problèmes d'accessibilité, et qu'avant d'en arriver à de tels extremes il y a d'autres possibilités plus efficaces comme envoyer ses pages en les compressant, avec un gain de 80 à 90% dixit le tableau (cf.
c'est à supposer que le serveur n'a qu'un seul site à gérer ! ! !
et je t'examine les pages et je regarde vers quel navigateur j'envoie (tien? comment fait-il pour savoir ça ?) et je te mouline en gzip et je cherche s'il me reste un peu de bande passante pour envoyer et à l'arrivée et je remouline en dégzip et je réfléchi à mon affichage et Merdum faut que je rappatrie les images ! Ah? y a un bouchon, faut attendre un peu ?
http://fravia.2113.ch/phplab/phpspeed.htm)
jeté un oeil rapide ==> mais ce n'est que pour ceux qui ont la main mise sur le serveur quels sont les hébergeurs qui offrent ces possibilités ?
Et de tte façon je suis sûr que ça ne fonctionne pas avec mon NC4.5 Le JS de grd papa ne lui pose pas de pb ;-))
Tu as envisagé de générer un tableau via javascript juste pour la
vitesse ? c'est bizarre comme raisonnement.
Tout dépend ce que tu as à générer comme tableau
Quand en une 12aine de lignes tu peux envoyer un calendrier à jour
au lieu du même tableau qui aura besoin de tte façon du JS des dates
Tu dois y gagner en temps de connexion/affichage
(en tous cas en RTC c'est flagrant)
Et si tu le généres en php, il faudra être bien patient que le serveur ait le temps
de s'occuper de ton cas puis qu'il envoie toute la tartine
temps de calcul (aléatoire) serveur-side + temps de txfer d'un gros fichier
contre
txfer de mini-fichier + temps de calcul sur un ordi qui n'a que ça à faire
c'est vite vu !
> J'en profite pour dire que la génération a base d'objet du DOM, en non
> seulement BEAUCOUP plus lente que le reste,
Oui mais après tu peux accéder à ces éléments via le DOM, ce qui est
plutôt interessant.
???
Si c'est juste pour récupérer des element.value ==> le DOM consomme plus de code
et m'étonnerait que les arrays du DOM soient plus rapides à gérer
Pour la création ça reste à voir
> quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas
> fait une erreur quelques part????
Je vais ptet passé pour un intégriste à barbe fou du texte brut,
mais générer un tableau avec JS juste pour réduire le temps de
téléchargement n'est pas une bonne méthode,
???
pour ceusses adesséllés (et qui fonctionne) peut-être, mais en RTC ???
car ça pose des problèmes
d'accessibilité, et qu'avant d'en arriver à de tels extremes il y a
d'autres possibilités plus efficaces comme envoyer ses pages en les
compressant, avec un gain de 80 à 90% dixit le tableau (cf.
c'est à supposer que le serveur n'a qu'un seul site à gérer ! ! !
et je t'examine les pages et je regarde vers quel navigateur j'envoie
(tien? comment fait-il pour savoir ça ?) et je te mouline en gzip et je cherche
s'il me reste un peu de bande passante pour envoyer et à l'arrivée
et je remouline en dégzip et je réfléchi à mon affichage et Merdum
faut que je rappatrie les images ! Ah? y a un bouchon, faut attendre un peu ?
http://fravia.2113.ch/phplab/phpspeed.htm)
jeté un oeil rapide ==>
mais ce n'est que pour ceux qui ont la main mise sur le serveur
quels sont les hébergeurs qui offrent ces possibilités ?
Et de tte façon je suis sûr que ça ne fonctionne pas avec mon NC4.5
Le JS de grd papa ne lui pose pas de pb ;-))
Tu as envisagé de générer un tableau via javascript juste pour la vitesse ? c'est bizarre comme raisonnement.
Tout dépend ce que tu as à générer comme tableau Quand en une 12aine de lignes tu peux envoyer un calendrier à jour au lieu du même tableau qui aura besoin de tte façon du JS des dates Tu dois y gagner en temps de connexion/affichage (en tous cas en RTC c'est flagrant) Et si tu le généres en php, il faudra être bien patient que le serveur ait le temps de s'occuper de ton cas puis qu'il envoie toute la tartine
temps de calcul (aléatoire) serveur-side + temps de txfer d'un gros fichier contre txfer de mini-fichier + temps de calcul sur un ordi qui n'a que ça à faire c'est vite vu !
> J'en profite pour dire que la génération a base d'objet du DOM, en non > seulement BEAUCOUP plus lente que le reste,
Oui mais après tu peux accéder à ces éléments via le DOM, ce qui est plutôt interessant.
??? Si c'est juste pour récupérer des element.value ==> le DOM consomme plus de code et m'étonnerait que les arrays du DOM soient plus rapides à gérer Pour la création ça reste à voir
> quelqu'un a deja fait le meme genre de test, que je puisse voir si j'ai pas > fait une erreur quelques part????
Je vais ptet passé pour un intégriste à barbe fou du texte brut, mais générer un tableau avec JS juste pour réduire le temps de téléchargement n'est pas une bonne méthode,
??? pour ceusses adesséllés (et qui fonctionne) peut-être, mais en RTC ???
car ça pose des problèmes d'accessibilité, et qu'avant d'en arriver à de tels extremes il y a d'autres possibilités plus efficaces comme envoyer ses pages en les compressant, avec un gain de 80 à 90% dixit le tableau (cf.
c'est à supposer que le serveur n'a qu'un seul site à gérer ! ! !
et je t'examine les pages et je regarde vers quel navigateur j'envoie (tien? comment fait-il pour savoir ça ?) et je te mouline en gzip et je cherche s'il me reste un peu de bande passante pour envoyer et à l'arrivée et je remouline en dégzip et je réfléchi à mon affichage et Merdum faut que je rappatrie les images ! Ah? y a un bouchon, faut attendre un peu ?
http://fravia.2113.ch/phplab/phpspeed.htm)
jeté un oeil rapide ==> mais ce n'est que pour ceux qui ont la main mise sur le serveur quels sont les hébergeurs qui offrent ces possibilités ?
Et de tte façon je suis sûr que ça ne fonctionne pas avec mon NC4.5 Le JS de grd papa ne lui pose pas de pb ;-))
Etienne SOBOLE wrote: > je dois afficher une centaine de ligne de 5 colonnes dans un tableau. > > Je m'interesse a la vitesse d'affichage (et dont implicitement de > téléchargement) > > j'ai donc essayé 4 méthodes! > - du html brute de fonderie > - du xhtml en placant le css dans un fichier a part > - la génération du tableau a base de document.write (en javascript donc) > - la génération du tableau a base de createElement, appendChild, ... (la > méthode à la mode) > > et ben on s'y attendais ou on s'y attendait pas, mais si on met a part le > download, l'ordre précedent est aussi celui allant du plus rapide au plus > lent...
Le tableau est-il affiché durant la construction ?
En html brut tu as le choix ?
Si oui cela cause probablement un énorme ralentissement, la page étant rafraîchie 500 fois.
Sinon en JS, sûr qu'il est + facile de le générer dans une variable et de ne faire écrire in fine que le contenu de la variable.
Etienne SOBOLE wrote:
> je dois afficher une centaine de ligne de 5 colonnes dans un tableau.
>
> Je m'interesse a la vitesse d'affichage (et dont implicitement de
> téléchargement)
>
> j'ai donc essayé 4 méthodes!
> - du html brute de fonderie
> - du xhtml en placant le css dans un fichier a part
> - la génération du tableau a base de document.write (en javascript donc)
> - la génération du tableau a base de createElement, appendChild, ... (la
> méthode à la mode)
>
> et ben on s'y attendais ou on s'y attendait pas, mais si on met a part le
> download, l'ordre précedent est aussi celui allant du plus rapide au plus
> lent...
Le tableau est-il affiché durant la construction ?
En html brut tu as le choix ?
Si oui cela cause probablement un énorme ralentissement,
la page étant rafraîchie 500 fois.
Sinon en JS, sûr qu'il est + facile de le générer dans une variable
et de ne faire écrire in fine que le contenu de la variable.
Etienne SOBOLE wrote: > je dois afficher une centaine de ligne de 5 colonnes dans un tableau. > > Je m'interesse a la vitesse d'affichage (et dont implicitement de > téléchargement) > > j'ai donc essayé 4 méthodes! > - du html brute de fonderie > - du xhtml en placant le css dans un fichier a part > - la génération du tableau a base de document.write (en javascript donc) > - la génération du tableau a base de createElement, appendChild, ... (la > méthode à la mode) > > et ben on s'y attendais ou on s'y attendait pas, mais si on met a part le > download, l'ordre précedent est aussi celui allant du plus rapide au plus > lent...
Le tableau est-il affiché durant la construction ?
En html brut tu as le choix ?
Si oui cela cause probablement un énorme ralentissement, la page étant rafraîchie 500 fois.
Sinon en JS, sûr qu'il est + facile de le générer dans une variable et de ne faire écrire in fine que le contenu de la variable.
Etienne SOBOLE wrote: > finalement, la methode la plus performant (et on va dire la plus equilibrée) > consiste a générer la page coté client en javascript a l'aide de > document.write... cela offre un equilibre correcte entre la taille- le temps > serveur - le temps client.
mais si pas de javascript, pas de table
C'est vrai que quand on use du JS on oublie les autres sans JS (sont-ils nombreux?) mais la soluce à ce pb, si on y est sensible, n'est tout de même pas sorcier ...
Etienne SOBOLE wrote:
> finalement, la methode la plus performant (et on va dire la plus equilibrée)
> consiste a générer la page coté client en javascript a l'aide de
> document.write... cela offre un equilibre correcte entre la taille- le temps
> serveur - le temps client.
mais si pas de javascript, pas de table
C'est vrai que quand on use du JS on oublie les autres sans JS (sont-ils nombreux?)
mais la soluce à ce pb, si on y est sensible, n'est tout de même pas sorcier ...
Etienne SOBOLE wrote: > finalement, la methode la plus performant (et on va dire la plus equilibrée) > consiste a générer la page coté client en javascript a l'aide de > document.write... cela offre un equilibre correcte entre la taille- le temps > serveur - le temps client.
mais si pas de javascript, pas de table
C'est vrai que quand on use du JS on oublie les autres sans JS (sont-ils nombreux?) mais la soluce à ce pb, si on y est sensible, n'est tout de même pas sorcier ...
ben, si je dois generer un tableau et que je veux que ca soit rapide, je le fais en server-side (php,asp,cfm...)
Ça ! ça veut dire que le serveur-side n'est pas débordé !
Pourquoi le serait-il ? (sauf cas particulier, cf free.fr)
Ça, ça veut dire qu'on a hyper léché son code. (qui le fait vraiment ?)
Les développeurs sérieux - quand on leur en laisse le temps.
Je n'y connais pas grd chose en php, et je l'ai vaguement essayé chez free
==>
bon, c'est cool le php, mais qu'est ce que ça peut ramer ! ! !
Non.
Les serveurs de chez free rament, en bonne partie parce que bon nombre d'incompétents y hébergent des sites en php+mysql alors qu'ils ne connaissent rien à la programmation, rien aux bases relationnelles, et qu'ils utilisent ça à tort et à travers.
Mais php en tant que tel est bien assez rapide pour ce qu'il a à faire.
Bruno
@SM wrote:
Thibaut Allender a *crit :
(snip)
ben, si je dois generer un tableau et que je veux que ca soit rapide, je
le fais en server-side (php,asp,cfm...)
Ça !
ça veut dire que le serveur-side n'est pas débordé !
Pourquoi le serait-il ? (sauf cas particulier, cf free.fr)
Ça,
ça veut dire qu'on a hyper léché son code.
(qui le fait vraiment ?)
Les développeurs sérieux - quand on leur en laisse le temps.
Je n'y connais pas grd chose en php,
et je l'ai vaguement essayé chez free
==>
bon,
c'est cool le php,
mais qu'est ce que ça peut ramer ! ! !
Non.
Les serveurs de chez free rament, en bonne partie parce que bon nombre
d'incompétents y hébergent des sites en php+mysql alors qu'ils ne
connaissent rien à la programmation, rien aux bases relationnelles, et
qu'ils utilisent ça à tort et à travers.
Mais php en tant que tel est bien assez rapide pour ce qu'il a à faire.
ben, si je dois generer un tableau et que je veux que ca soit rapide, je le fais en server-side (php,asp,cfm...)
Ça ! ça veut dire que le serveur-side n'est pas débordé !
Pourquoi le serait-il ? (sauf cas particulier, cf free.fr)
Ça, ça veut dire qu'on a hyper léché son code. (qui le fait vraiment ?)
Les développeurs sérieux - quand on leur en laisse le temps.
Je n'y connais pas grd chose en php, et je l'ai vaguement essayé chez free
==>
bon, c'est cool le php, mais qu'est ce que ça peut ramer ! ! !
Non.
Les serveurs de chez free rament, en bonne partie parce que bon nombre d'incompétents y hébergent des sites en php+mysql alors qu'ils ne connaissent rien à la programmation, rien aux bases relationnelles, et qu'ils utilisent ça à tort et à travers.
Mais php en tant que tel est bien assez rapide pour ce qu'il a à faire.
Bruno
Steph. k.
@SM wrote: [...]
Je n'y connais pas grd chose en php, et je l'ai vaguement essayé chez free
==>
bon, c'est cool le php, mais qu'est ce que ça peut ramer ! ! !
Free est une catastrophe au niveau php et encore pire dès qu'on utilise mysql, essaye ailleurs (nexenservices, 15 jours gratuits). Pour un tableau il faut faire gaffe à bien utiliser la balise <colgroup> pour que le navigateur puisse calculer les dimensions du tableau dès le début de l'envoi des données. Voir la page suivante pour plus de détails : http://www.acces-pour-tous.net/fichiers_communs/access.php?rub=tableaux
-- Steph. K. http://www.acces-pour-tous.net Quand le merle chante en mai, avril est fini. Coluche
@SM wrote:
[...]
Je n'y connais pas grd chose en php,
et je l'ai vaguement essayé chez free
==>
bon,
c'est cool le php,
mais qu'est ce que ça peut ramer ! ! !
Free est une catastrophe au niveau php et encore pire dès qu'on utilise
mysql, essaye ailleurs (nexenservices, 15 jours gratuits).
Pour un tableau il faut faire gaffe à bien utiliser la balise
<colgroup> pour que le navigateur puisse calculer les dimensions du
tableau dès le début de l'envoi des données. Voir la page suivante pour
plus de détails :
http://www.acces-pour-tous.net/fichiers_communs/access.php?rub=tableaux
--
Steph. K.
http://www.acces-pour-tous.net
Quand le merle chante en mai, avril est fini.
Coluche
Je n'y connais pas grd chose en php, et je l'ai vaguement essayé chez free
==>
bon, c'est cool le php, mais qu'est ce que ça peut ramer ! ! !
Free est une catastrophe au niveau php et encore pire dès qu'on utilise mysql, essaye ailleurs (nexenservices, 15 jours gratuits). Pour un tableau il faut faire gaffe à bien utiliser la balise <colgroup> pour que le navigateur puisse calculer les dimensions du tableau dès le début de l'envoi des données. Voir la page suivante pour plus de détails : http://www.acces-pour-tous.net/fichiers_communs/access.php?rub=tableaux
-- Steph. K. http://www.acces-pour-tous.net Quand le merle chante en mai, avril est fini. Coluche
Thibaut Allender a ecrit :
mais une solution avait ete donnee ici pour rendre valide le couple object + embed
On peut dire ça comme ça... Mais en ce qui me concerne, tu peux ajouter NS4 dans la même liste que IE. Un browser qui ne supporte pas le DOM (getElementByTagName, getElementById etc) ne supporte pas javascript de mon point de vue (j'entends par là que je me désintéresse de ce qu'il supporte ou non s'il faut coder autrement).
Il fut une époque où on stipulait la version du JS dans le tag N'existe t-il pas une méthode identique pour le DOM ?
et puis il n'est pas si compliqué de mettre un p'tit if(document.getElementById) .../... else
Outre le fait que ce n'est pas le même type d'outil (cf remarque ci-avant), qu'est-ce qui t'empêche d'utiliser PHP ?
1) l'apprentissage 2) ma quasi obligation de tester sur site avec tous les désagréments de txfers 3) j'aime bien le JS de grd papa 4) "mon" site est chez wanadoo en pages-perso
> (ie : formulaires qui n'ont pas besoin de faire des a-r car incomplets) Ok pour ça - et encore, certaines vérifs peuvent nécessiter un a-r.
On peut dire ça comme ça... Mais en ce qui me concerne, tu peux ajouter
NS4 dans la même liste que IE. Un browser qui ne supporte pas le DOM
(getElementByTagName, getElementById etc) ne supporte pas javascript de
mon point de vue (j'entends par là que je me désintéresse de ce qu'il
supporte ou non s'il faut coder autrement).
Il fut une époque où on stipulait la version du JS dans le tag
N'existe t-il pas une méthode identique pour le DOM ?
et puis il n'est pas si compliqué de mettre
un p'tit
if(document.getElementById)
.../...
else
Outre le fait que ce n'est pas le même type d'outil (cf remarque
ci-avant), qu'est-ce qui t'empêche d'utiliser PHP ?
1) l'apprentissage
2) ma quasi obligation de tester sur site
avec tous les désagréments de txfers
3) j'aime bien le JS de grd papa
4) "mon" site est chez wanadoo en pages-perso
> (ie : formulaires qui n'ont pas besoin de faire des a-r car incomplets)
Ok pour ça - et encore, certaines vérifs peuvent nécessiter un a-r.
On peut dire ça comme ça... Mais en ce qui me concerne, tu peux ajouter NS4 dans la même liste que IE. Un browser qui ne supporte pas le DOM (getElementByTagName, getElementById etc) ne supporte pas javascript de mon point de vue (j'entends par là que je me désintéresse de ce qu'il supporte ou non s'il faut coder autrement).
Il fut une époque où on stipulait la version du JS dans le tag N'existe t-il pas une méthode identique pour le DOM ?
et puis il n'est pas si compliqué de mettre un p'tit if(document.getElementById) .../... else
Outre le fait que ce n'est pas le même type d'outil (cf remarque ci-avant), qu'est-ce qui t'empêche d'utiliser PHP ?
1) l'apprentissage 2) ma quasi obligation de tester sur site avec tous les désagréments de txfers 3) j'aime bien le JS de grd papa 4) "mon" site est chez wanadoo en pages-perso
> (ie : formulaires qui n'ont pas besoin de faire des a-r car incomplets) Ok pour ça - et encore, certaines vérifs peuvent nécessiter un a-r.
Heu... A propos de respect des standards : - nécessite javascript + flash
Ha ! y m'semblait bien qu'on était un peu dans la contradiction là! (php sans js) mais bon ! moi j'aime bien le JS (mais pas le beurk flash)
- doctype HTML (sans l'url de la DTD) alors que le doc est en xhtml
Hou ! Le vilain ! :-)))
dommage pour @SM s'il ne peut pas le voir dans des conditions décentes,
Si, si! tout de même! si je veux, je peux :-)) Mais ça me gratte ... :-) je pense à l'autre qui peut pas.
moi je trouve l'ensemble assez classieux !-)
Faut reconnaître bien que ... pas beaucoup en Français et ss doute encore mieux en 20" Serait-il possible de fluidifier le menu ? (à moins que ça ne saccade que chez moi ?)
Heu... A propos de respect des standards :
- nécessite javascript + flash
Ha ! y m'semblait bien qu'on était un peu dans la contradiction là!
(php sans js)
mais bon ! moi j'aime bien le JS (mais pas le beurk flash)
- doctype HTML (sans l'url de la DTD) alors que le doc est en xhtml
Hou ! Le vilain ! :-)))
dommage pour
@SM s'il ne peut pas le voir dans des conditions décentes,
Si, si! tout de même! si je veux, je peux :-))
Mais ça me gratte ... :-) je pense à l'autre qui peut pas.
moi je trouve l'ensemble assez classieux !-)
Faut reconnaître
bien que ... pas beaucoup en Français
et ss doute encore mieux en 20"
Serait-il possible de fluidifier le menu ?
(à moins que ça ne saccade que chez moi ?)
Heu... A propos de respect des standards : - nécessite javascript + flash
Ha ! y m'semblait bien qu'on était un peu dans la contradiction là! (php sans js) mais bon ! moi j'aime bien le JS (mais pas le beurk flash)
- doctype HTML (sans l'url de la DTD) alors que le doc est en xhtml
Hou ! Le vilain ! :-)))
dommage pour @SM s'il ne peut pas le voir dans des conditions décentes,
Si, si! tout de même! si je veux, je peux :-)) Mais ça me gratte ... :-) je pense à l'autre qui peut pas.
moi je trouve l'ensemble assez classieux !-)
Faut reconnaître bien que ... pas beaucoup en Français et ss doute encore mieux en 20" Serait-il possible de fluidifier le menu ? (à moins que ça ne saccade que chez moi ?)
