visualizzazione div a tempo

[carlomarx]

Originariamente inviato da Virus_101
Sei te che polemizzi

Cioè: non so se ti rendi conto di quello che stai creando in una discussione che aveva come titolo "visualizzazione div a tempo"! Tra l'altro discutendo di ciò che piace fare al sottoscritto (argomento di cui credo non importi niente a nessuno).

Originariamente inviato da Virus_101
??? beh davvero getiscsiti te i callbacks con js antivo con
timer = window.setTimeout(function(){} , interval ) ; e tutti callbacks dentro i callbask etc....
sei folle se dici cosi'
$("elemet").animate({css},time,function(){ /*mia funzione di callback*/ }) fallo in codice nativo js e dimmi se swcrivere quella marea di gestori e' piu' comodo di scrivere una normale chiamata jquery

Lo faccio continuamente, mi piace farlo e di solito me la cavo sempre con pochissime righe di codice. Te l'ho detto, non amo e non uso jQuery.

Originariamente inviato da Virus_101
Certo che vuole dire quacosa ossia la tecnica di protitipiazzazione e' proprio quelle che fai pure te quando devi aggiungere al volo metodi, proprieta etc... visto che js NON E' OOP!

Sì, certo, aggiungo anch'io i metodi ai prototipi quando non voglio cleare closures. Ma qui si sta parlando semplicemente di una funzione nativa di js (forEach) molto simile ad each di jQuery, il cui accesso è però nativamente annidato nel prototipo di Array ed è quindi lì che lo dobbiamo andare a pescare quando lo vogliamo applicare ad esempio a una NodeList, qual è una collezione di elementi del DOM con medesima classe. Non c'entra nulla la "prototipizzazione".

Originariamente inviato da Virus_101
Jquery non e' solo $ e' un sacco di altre cose.

Certo. Se fosse solo $ lo sponsorizzerei anch'io

Originariamente inviato da Virus_101
JAVASCRIPT NON E' UN LINGUAGGIO AD OGGETI!!!!!
Js e' un linguaggio funzionale. gli oggetti sono "travisamenti" la vera natura di javascript e' funzionale e quando lo capirete sarà un grande giorno.

Qui ti sbagli. La confusione che spesso si fa riguarda le classi, locuzione con cui vengono erroneamente chiamati spesso i costruttori. JavaScript non possiede delle classi, come invece hanno altri linguaggi. Ma non per questo puoi dire che non possegga gli oggetti o che non possegga i prototipi e i costruttori o che non sia object oriented. Si tratta semplicemente di un modo diverso di serializzare la costruzione degli oggetti.

Originariamente inviato da Virus_101
In js sono tutte funzioni, e lo scoping con enclosure e i callbacks, la gestione delle chiamate asicnrone etc... come fatto in js lo testimonia . Se non lo vedi mi dispiace per te ma continuerai a non capire cosa stai usando.

In parte falso, in parte incomprensibile. A meno che non usi la parola "funzionale" per descrivere un linguaggio che per serializzare gli oggetti utilizza dei costruttori (e quindi delle funzioni) invece che delle classi: in tal caso la tua affermazione sarebbe tutta falsa. Gli oggetti non sono funzioni, i valori primitivi non sono né funzioni né oggetti, le funzioni non sono oggetti, etc. etc. In JS solo le funzioni sono funzioni.
E nemmeno lo scoping è legato unicamente alle funzioni. Esiste l'operatore "let", che puoi usare in campo libero, esistono gli scope separati dei Worker: esiste un mondo che se ti ostini a usare jQuery non conoscerai mai, perché jQuery, per motivi di "economicità", fa un abuso delle funzioni.

Originariamente inviato da Virus_101
Json (e' notazione OO ma sempre in contesto funzionale tanto che se noti non gestisci los coping degli attributi/metodi etc...) cmq, tale notazione e l'utilizzo massiccio che ne fanno i vari frameowrk come jquery serve appunto per rendere piu' OOP style un linguaggio che nativamente non lo e'!!!!

Prima di tutto chiariamo. JSON è una sintassi da applicare a una stringa. Per capirci, questo è JSON:

var tuaStringa = "{ \"animale\" : \"cane\" }";

questo non lo è:

var tuoOggetto = { "animale": "cane" };

In questo secondo caso si parla di istanzializzazione letterale di un oggetto. E, sinceramente, credo che jQuery ne faccia un abuso. E, soprattutto, non cambia di una virgola la natura OOP di JS.

Originariamente inviato da Virus_101
in js non fai class miaClasse(){ public miaClasse(){} } etc...
ma fai var a = function(){ } !!! NON E' OOP !!!!

Vedi sopra. È perfettamente OOP. Sei tu a continuare a considerare i costruttori alla stessa stregua delle classi. JavaScript non possiede classi. Possiede i costruttori, ovvero qualcosa di meglio delle classi.

Originariamente inviato da Virus_101
Comprendo la necessità di ottimizzare, ma non oltre un certo limite le tecnologie avanzano e se non puoi starci al passo cambia mestiere. Se serve un pc con potenza x per far girare qualcosa o lo hai o amen ... non poi pretendere che il mondo si fermi perche' il tuo pc non e' potente a sufficenza.
Io sono dell'idea cmq che su questo punto il web sia sbagliato e sia sbagliato usare un l,iguaggio come js per animare delle pagine web che sono nate per essere solamente dei documenti. Serve un formato nuovo ma davvero nuovo. Che decisamente sfrutti meglio l'hw.
Usiamo js per fare manipolare gli oggetti che vengono ri-renderizzati dai browser ... con uno spreco assurdo in termini di risorse. e un pc che fa girare battlefield3 si trova a scattare con una fotogallery.

Ottimizzare è una cosa complessa. Vatti a guardare il sorgente di questa scacchiera 3D: http://htmlchess.sourceforge.net/demo/example.html (devi cliccare su 3D view), guarda quant'è stato complesso costruire i profili tridimensionali di tutti i pezzi, e dimmi se va a scatti. Sul mio vecchio PC va alla grande. Sarà forse che non abbiamo usato librerie?

Originariamente inviato da Virus_101
Certo qui sono daccorod con te, ma ricorda che quando lavori le retocompatibilità sono importanti, e purtroppo (quasi esclusivamente colpa di InternetExplorer) non potremo usare html5 tranquillamente per molto tempo. QUindi mettitela via html5 e' un flop. Lavora bene solo sul mobile che non ha ie, in ogni altro contesto o fai la doppia versione di tutto(per avere i siti che funzionano anche dai clienti) oppure ti agganci, e per questo mi girano le balle, perche' come dico a te aggiornati dovrei dirlo a mezzo mondo. Ma i clienti non lo fanno e le mie web apps devono girare da i7 in su ... e quindi che faccio ? Perdio 4 giorni soilo per fare la versione html5 e quella html4 e precedenti ????

Giuro che io quasi mi diverto a rendere compatibile per IE ciò che non lo è, soprattutto se riesco a mantenere la sintassi standard A me JavaScript piace, non ho nulla da ridire. L'unica volta che sono entrato in polemica con ECMAScript è stato a proposito della deprecazione di arguments.callee, motivo per cui ho aperto un bug, cercando di dimostrare che si sarebbe creata una lacuna riguardante il costruttore di funzioni new Function("..."). Per il resto lo trovo un linguaggio molto elegante. Trovo goffi solo alcuni metodi del DOM, come document.getElementsByClassName (ma un nome più breve no???). Ma in questo caso non si tratta di JavaScript, il DOM è una cosa che ECMAScript nemmeno tratta, perché riguarda l'applicazione di un linguaggio generico come JS a una cosa specifica come delle pagine web. E infatti gli standard del DOM (come document.getElementsByClassName) è il W3C a dettarli e non ECMAScript.

Cerca di abbassare la cresta, fa' meno il profeta e resta a tema coi titoli dei thread.

[Virus_101]

Ripondo sui punti in cui sono tuttora in disaccordo :

1- gestire i trimers ti garba ? Beh ripeto contento te a doverti fare sturrure dati per tenere traccia di tutti i timers che partono per le chiamate di animazione asicrone che sei costretto a lanciare.

2- su protitipizzazione siamo accordo e certo jquery usa e abusa,e spesso rende gli oggetti pesanti perche' appunto innesta se' stessa (come lib) nell'oggetto, ma rende disponiobili un sacco di cose che altrimenti dovresti sbroccare per avere

3- "javascript non possiede classi" => non e' ad oggetti!!!!!! Ripeto non lo e' e non ci sono discussioni che tengano, sintassi o meno. Js sono tutti e solamente puntatori a funzioni, e non sono oggetti anche se sono erroneamente chiamati cosi'. NON LO SONO!
ja fa uso di lambda calcolo per gestire oggertti (var a = function(){ ... } ) e questa sintassi e' propria dei linguaggi funzionali. E js e' appunto il linguaggio funzionale piu' popolare attualmente usato. Il fatto che si simuli il paradigma OOP non rende tale linguaggio OO . Serializza gli oggetti come ti pare ... ma resta il fatto che sono puntatori a funzioni e viene tutto gestito con lambda calcolo.

4- So cos'e json e lo uso spesso per comodita' per gestire ajax responses in quanto ha un overhead quasi nullo e risulta in un minore troughtput sul server rispetto ad xml, inoltre e' 30000 mila volte meglio che gestire i risultati con csv . Unitamente al fatto che come formato di serializzazione e' 1 bomba e mi consente di poter generare le strutture dati direttamente dal linguaggio del server (quasliasi esso sia) e rendere tali strutture direttamente manipolabili in js senza dover scriver parsers o altro.
e ripeto var a = function(){} NON e' OOP e non possiede un costruttore !!
Il costruttore te lo devi simulare
var a = function(){
this.pubblica = "sono pubblica"
var a = "ciao" ;
var self = this ;

this.build = function(){/*setta attributi e valori*/}

this.build();
}

Chiamala OOP questa e veramente rido. Unitamente al fatto che per avere lo scoping di "this" nei metodi "poseudo"privati devo dichiare la var self ( e giu di enclosure ) .
non ho le dichiarazioni private, public, protected. .,. Non estendo, non creo interfaccie ... ma devo prototipizzare ... NON E' OOP !


Secondo te inoltre questo nn e' JSON ???
var tuoOggetto = { "animale": "cane" };

DIo mio ... JSON => Java Script Object Notation , la stringa proposta da te e' l'oggetto da serializzare ma l'oggetto passato (lo chiamo oggetto per contestualizzare ma fondamentalmente e' una struttura) non e' altro che il risultato di un "eval" sulla stringa.Il formato e' JSON, la stringa JSON diventa un oggetto js certo, la stringa e' il JSON l'oggetto e' l'oggetto ... non c'e' molto da dire a riguardo, se non che e' un metodo comodo per passare dati a procedure, e rendere anche tali procedure facilmente estensibili ..


5- bellina si la scacchiera. Ma posso chiedere 1 cosa .... che dormato avete usato no avrete mica fatto tutto calcolandovi i punti manualmente in 3d? Spero abbiate fatto i pezzi un VRML a partire da blender 3d altrimenti sei/siete fuori come meloni.
io avrei preso i modelli vrml e creato l'appostio converter... per inserire le mesh nel motore.
P.S.
Se in html5 puoi usare le canvas e puoi disegnare punti e lineee, il resto e' solo questione di tempo.
Ovvio che in jquery nn fai queste cose, ma a che servono ? Nei siti jquery ha tutt'altro scopo e il 90% dei casi in cui serve js serve per altre cose.

6- se ti diverti a rendere compatibile IE fatti tuoi per me e' solo 1 perdita di tempo. E in azienda il tempo e' denaro, e meno tempo ci vuole per ottenere un risultato cross browser meglio e'. I jquery abbbiamo notato un abattimento dei tempi di sviluppo in js di oltre il 70% ... dimmi se e' poco....

Sinceramente chi deve abbassare la cresta sei te, se tu lavori in un modo non e' detto che debba farlo il mondo, vito che il mondo lavora con jquery. Devi capire le fondamentali necessità temporali dis viluppo sul lavoro, delle compatibilità e delle retrocompatibilità.

Non ho mai fatto il "profeta" come dici te. Ma semplicemente detto che per certi casi per me e' meglio usare un framework visti i tempi di sviluppo e le compatibilità da affrontare.

Su una cosa hai pero' ragione che siamo completamente Off Topic.
Se vuoi ne parliamo in sepato thread.

[carlomarx]

Di certo non chiedo a nessuno di fare come piace fare a me… Cmq:

1. Dipende da quello che devo fare. Se devo crearmi un singolo effetto animato, lavoro semplicemente su quello, come ho fatto qui: http://forum.html.it/forum/showthrea...eadid=1497676. Se invece devo modificare massivamente molti dati, come ad esempio molte proprietà del DOM contemporaneamente, mi creo delle librerie apposite ottimizzate per l'occorrenza. E guarda caso spesso mi trovo a lavorare in direzione opposta a come fa jQuery. Ad esempio, proprio per evitare l'abuso degli oggetti che fa jQuery e lo spreco di memoria e di parsing che ne deriva, avevo escogitato questa soluzione (che avevo chiamato "domQuery"): https://developer.mozilla.org/en/Jav...nction#Example

2. Per quanto riguarda l'object oriented, il problema è che fai confusione con lo scoping. Si tratta di due questioni completamente diverse. JavScript è sempre stato un linguaggio object oriented, ma era carente fino a poco tempo fa per quanto riguardava lo scoping. Per questo motivo è stato inventato l'operatore let, che ha egregiamente risolto un bel po' di problemi, soprattutto per quanto riguardava l'abuso del currying:

<script type="text/javascript;version=1.7">
	var a = 5;
	let (a = 6) {
		a++;
		alert(a); // 7
	}
	alert(a); // 5
</script>

Come vedi non si fa uso di funzioni…

3. Che vuol dire che var a = function () {} non possiede un costruttore??? In js solo gli oggetti speciali null e undefined non posseggono costruttori: in questo caso il costruttore di a è Function:

var a = function () {};
alert(a.constructor); // Function
var b = new a.constructor("alert(\"Ciao mondo!\");");
b(); // "Ciao mondo!"

Semmai, mi dirai, il vero problema di Function è che è un costruttore non protitizzabile:

function FunzioneSpeciale () {}
FunzioneSpeciale.prototype = new Function("");
alert(new FunzioneSpeciale()); // errore

La risposta è sì, c'è un bug.
Io credo che il vero problema di JavaScript è che è spesso un linguaggio sconosciuto a chi lo usa.
Adesso vado, se vuoi apri un thread apposito.

[br1]

Ok, basta con le seghe mentali, il cliente e' soddisfatto e voi per le vostre dotte disquisizioni potete aprire una discussione tutta vostra nella quale scannarvi.

Non che non ci interessino i punti di vista (anzi! ) ma questo non e' il posto giusto.

@ bigrattle: se necessario puoi aprire un'altra discussione, scusa la bagarre