PHWinfo - Afficher un message - ajouter automatiquement du code HTML juste derriere tous les textareas d'une page

25/06/2007, 15h17

ASM a écrit :
> Bruno Desthuilliers a écrit :
>> ASM a écrit :
>>>
>>> Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est)
>>
>> Un processeur AMD 32 bits cadencé à =~ 1550 Mhz,
>
> ha ben tu m'aurais dit un AMD32/1550 j'aurais compris :-)
> Ça doit être aussi bien sinon mieux qu'un G4/400,

Pas assez d'éxpérience du G4 pour te dire

> ou bien est-ce au
> niveau d'un G3/266 ?

S'il te plait... J'ai dit "bousin vieillissant", pas "ossement de
dinosaure" !->

>>> C'est juste une question de principe : je connais certains qui n'ont
>>> pas l'ADSL.
>>
>> J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec
>> IE5 mac.
>
> oui, aussi.
> Et sur PC AMD K6II/500 Win95 ...

Ca par contre je connais pas.

>> D'autre part, le recours à Ajax permet d'éviter des rechargements
>> *complets* de la page, et donc, une fois la bibliothèque montée en
>> cache, un net gain de perfs *particulièrement* pour ceux qui ont un
>> faible débit.
>
> Oui.
>
> Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi
> ... me semble-ce.

Si tu additionne le code nécessaire pour chaque requête plus le code
pour traiter le résultat de chaque requête, t'a vite fait d'avoir un
paquet de lignes de code. Même si le poids total de ce code reste
inférieur à celui de la biblio + le code spécifique appelant la biblio,
ça n'empêche que tu a tout ce code à écrire *et* à maintenir. Au prix de
la journée de développeur, ce n'est pas économiquement envisageable.
Particulièrement quand tes clients sont assez informés pour connaître
eux-mêmes ces bibliothèques, ce qui est le cas dès que tu a un service
informatique en face de toi.

>>> En outre les JS n'ont pas été chargés pour rien, probablement ils
>>> vont agiter un tas de choses comme de faire charger d'autres sources
>>> (ce qui ne va pas accélérer l'affichage final).
>>
>> Ah bon ?
>
> Il y en a qui font écrire des pages complètes via JS (y compris les
> insertions d'images, vidéos, étoussa).

Il y a des andouilles partout, suffit de lire le daily WTF pour s'en
convaincre.

> Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?).

Coldfusion est une techno serveur propriétaire... je ne vois pas le
rapport avec js...

>> Tu sais, en général, quand on utilise ajax pour "charger d'autres
>> sources", on le fait *après* que la page ait été chargée.
>
> ... ça dépend ... on peut avoir le skin/mise-en-page en "normal" et tout
> le(s) contenu(s) en Ajax.

personnellement, j'ai plutôt des templates distinct pour tous les
composants "ajaxifiables", et un template principal qui rappelle ces
composant, directement au chargement de la page complète, via ajax (si
js activé) après.

> mais ce n'est pas grave : une roue de secours a été habilement prévue :-)
> mais le poids de la page d'entrée n'est pas réduit totomatiquement parce
> qu'on ajaxionne,

Non, mais ça évite quand même de recharger toute la page quand on veut
juste mettre à jour un petit fragment.

25/06/2007, 15h17	#68
Bruno Desthuilliers Messages: n/a Hébergeur:	Re: ajouter automatiquement du code HTML juste derriere tous lestextareas d'une page ASM a écrit : > Bruno Desthuilliers a écrit : >> ASM a écrit : >>> >>> Je n'ai pas d'athlon XP1800 (et ne sais pas ce que c'est) >> >> Un processeur AMD 32 bits cadencé à =~ 1550 Mhz, > > ha ben tu m'aurais dit un AMD32/1550 j'aurais compris :-) > Ça doit être aussi bien sinon mieux qu'un G4/400, Pas assez d'éxpérience du G4 pour te dire > ou bien est-ce au > niveau d'un G3/266 ? S'il te plait... J'ai dit "bousin vieillissant", pas "ossement de dinosaure" !-> >>> C'est juste une question de principe : je connais certains qui n'ont >>> pas l'ADSL. >> >> J'en connais aussi qui ont encore un vieux mac sous Os8 ou Os9, avec >> IE5 mac. > > oui, aussi. > Et sur PC AMD K6II/500 Win95 ... Ca par contre je connais pas. >> D'autre part, le recours à Ajax permet d'éviter des rechargements >> complets de la page, et donc, une fois la bibliothèque montée en >> cache, un net gain de perfs particulièrement pour ceux qui ont un >> faible débit. > > Oui. > > Mais l'Ajax (basique XHR) ce n'est que 10 à 20 ko maxi > ... me semble-ce. Si tu additionne le code nécessaire pour chaque requête plus le code pour traiter le résultat de chaque requête, t'a vite fait d'avoir un paquet de lignes de code. Même si le poids total de ce code reste inférieur à celui de la biblio + le code spécifique appelant la biblio, ça n'empêche que tu a tout ce code à écrire et à maintenir. Au prix de la journée de développeur, ce n'est pas économiquement envisageable. Particulièrement quand tes clients sont assez informés pour connaître eux-mêmes ces bibliothèques, ce qui est le cas dès que tu a un service informatique en face de toi. >>> En outre les JS n'ont pas été chargés pour rien, probablement ils >>> vont agiter un tas de choses comme de faire charger d'autres sources >>> (ce qui ne va pas accélérer l'affichage final). >> >> Ah bon ? > > Il y en a qui font écrire des pages complètes via JS (y compris les > insertions d'images, vidéos, étoussa). Il y a des andouilles partout, suffit de lire le daily WTF pour s'en convaincre. > Coldfusion ? ou je ne sais plus trop quoi ni lesquels (prototype?). Coldfusion est une techno serveur propriétaire... je ne vois pas le rapport avec js... >> Tu sais, en général, quand on utilise ajax pour "charger d'autres >> sources", on le fait après que la page ait été chargée. > > ... ça dépend ... on peut avoir le skin/mise-en-page en "normal" et tout > le(s) contenu(s) en Ajax. personnellement, j'ai plutôt des templates distinct pour tous les composants "ajaxifiables", et un template principal qui rappelle ces composant, directement au chargement de la page complète, via ajax (si js activé) après. > mais ce n'est pas grave : une roue de secours a été habilement prévue :-) > mais le poids de la page d'entrée n'est pas réduit totomatiquement parce > qu'on ajaxionne, Non, mais ça évite quand même de recharger toute la page quand on veut juste mettre à jour un petit fragment.