On Tue, 10 Jun 2008 01:54:29 -0700 (PDT), Sabrina wrote:
Quote:
perché deve ricostruire il layout per la bellezza di 5000 righe
Ma va scattoso DOPO che la tabella ha già finito di caricarsi! |
Appunto. Forse non ti è chiaro l'infrastruttura di una applicazione
web based: richiedere al server una table con 5000 righe è il meno,
soprattutto in una intranet. Devi contare che poi queste 5000 righe
le devi aggiungere al document tree, e già questa operazione su dei
PC potrebbe "congelare" il browser; in più devi considerare che una
volta caricate, il browser si ritrova a gestire una pagina MOLTO MA
MOLTO più pesante di prima (quando 5000 righe neppure c'erano). Non
solo è scattoso anche su cose "native", come lo scrolling oppure il
resize, ma soprattutto su tutti quegli effetti realizzati da script
e che vanno a toccare le proprietà di rendering (CSS).
Quote:
Io vedo
sotto, in trasparenza, che la tabella c'è già. Però ci mette una vita
a fare il ciclo per togliere opacità al pannello. |
E' ovvio: prima il browser si deve limitare a renderizzare un certo
numero di elementi, poi ha davanti a sé lo stesso numero più 5000..
In più, le animazioni in JS si fanno usando i timeout/interval, che
non vanno su un thread differente, così come lo script engine te lo
trovi sulla stessa pipeline delle render engine.
Quote:
5000 righe ???
Hai presente il significato di "paginazione" ?? 
Si ho presente il significato di paginazione ma gli utenti non la
vogliono. |
Sai, anche io vorrei un sistema informatico a performance infinite,
ma puoi dire ai tuoi utenti che ancora non esiste. Esistono invece,
cose chiamate "limiti tecnici", che non puoi superare a meno di non
cambiare tecnologia (ad esempio, ti rifai tutto in Flex/Flash).
Prego.
--
~ "Chi ci priva della libertà in nome della sicurezza,
non si merita nessuna delle due cose, nè la libertà,
nè la sicurezza." (Henry Adams)