Yahoo! User Interface Blog (YUIBlog)

Dissezione 3.5.0 DataTable, Part 1

1 maggio 2012 alle 12:43 am da Luke Smith | In Development | Nessun Commento

DataTable è stato uno dei YUI più pesantemente utilizzati e considerati affidabili widget per anni. In 3.5.0, DataTable ha una profonda revisione, con conseguente alcune piccole modifiche alle API e alcune grandi cambiamenti alle infrastrutture.

In questo articolo in due parti, parleremo di questi cambiamenti, ciò che ha portato alla decisione di rivedere l'infrastruttura piuttosto che concentrarsi sulle funzioni, abbattere alcuni dei concetti nuovi e sperimentali di essere esplorati, e finire con uno sguardo al piano per il futuro della DataTable come lo vediamo oggi.

Quindi, senza ulteriori indugi, andiamo affrontare l'ovvia domanda:

Perché refactoring?

La risposta breve è "per rendere più facile DataTable da usare e personalizzare". La 3.4.1 infrastruttura è stata basata su un modello "core" Widget, con tutte le funzioni aggiuntive da sinistra a plugin o sottoclassi. I dati si è svolta in un Y.Recordset istanza e la configurazione di colonna in una Y.Columnset esempio. Il widget è stato responsabile della creazione del markup intera tabella. Che sembrava una architettura ragionevole, ma c'erano alcuni problemi con questo:

1. DataTable sono definite per le loro caratteristiche, il che significa che ci potrebbe essere un sacco di plug() ing per ottenere la DataTable che misura la vostra applicazione. Questo ha reso lavorare con DataTable troppo complicato e prolisso.
2. Il contratto del Plugin API ostacolato DataTable caratteristiche multiple di interagire in modo corretto. In effetti, alcune caratteristiche DataTable in 3.4.1 aveva già iniziato rompere questo contratto.
3. DataTable è stato difficile codificato da usare Y.Record , Y.Recordset , Y.Column e Y.Columnset . Questo accoppiamento limitato la possibilità di personalizzare DataTable o integrare con altri componenti dell'applicazione.
4. L'algoritmo di rendering era flessibile, ma i suoi ganci sono stati fissati per la personalizzazione. C'è stata l'occasione per fare il rendering più personalizzabile (e un bel po 'più veloce) senza richiedere agli implementatori di fare interventi di chirurgia maggiore sulle loro istanze.

La nuova architettura si propone di affrontare questi ed altri temi scoperto durante la sua vita la produzione prima della 3.5.0, e approfittare delle quadro Dietro le componenti che non erano in giro quando DataTable è stato inizialmente creato nel 3.3.0.

DataTable è incredibilmente importante per un sacco di gente, ed è importante per noi che non solo essere costruito a destra, ma anche che sia facile da usare possibile. Queste modifiche mirano a spostare DataTable nella giusta direzione.

Grandi cambiamenti

Le principali modifiche da 3.4.1 a 3.5.0 sono per lo più sotto il cofano, e con po 'di fortuna, la migrazione a 3.5.0 DataTable dovrebbe essere indolore.

La maggior parte dei cambiamenti esteriori alle API di rendere molto più facile da aggiungere e utilizzare le funzioni DataTable. Confrontare un 3.4.1 ordinabile DataTable al suo equivalente 3.5.0:

Cosa c'è in un nome?

La prima cosa che noterete è che dal 3.5.0, è possibile creare istanze di Y.DataTable piuttosto che Y.DataTable.Base . La classe base è ancora in giro, ma ora il suo ruolo primario è come una superclasse per l'estensione (che ne parleremo in dettaglio nel prossimo articolo).

Y.DataTable ora è la classe principale e lo spazio dei nomi per le classi che supportano DataTable, come Y.DataTable.Base , Y.DataTable.Sortable e Y.DataTable.BodyView . L'unica eccezione degna di nota è Y.Plugin.DataTableDataSource , che non è ancora stata eseguita la migrazione verso il nuovo ordine mondiale (si aspettano che in 3.6.0).

Vedrete di più su questo nel prossimo articolo, quando si parla di alcuni dei nuovi concetti DataTable.

Caratteristiche come estensioni di una classe

L'architettura 3.5.0 segna un allontanamento dal modello di plugin per DataTable. Al contrario, stiamo mettendo le funzionalità di estensioni di classe, e utilizzando il potente Y.Base.mix() metodo per aumentare queste caratteristiche nella classe DataTable, creando una sorta di ad-hoc modello di ereditarietà multipla.

I due vantaggi principali è questo approccio sono i seguenti:

1. L'API per la vostra DataTable e tutte le sue caratteristiche è in un posto, il Y.DataTable istanza.
2. Piuttosto che dover costruire in modo esplicito il tuo DataTable dalla base, è sufficiente compresi i moduli di funzionalità nel vostro use() riga aggiunge il supporto per le caratteristiche del Y.DataTable classe.

Ma che cosa se avete un paio di DataTable sulla pagina, e non volete tutte ordinabili o scorrevole, ecc?

Per mantenere le caratteristiche di fuoriuscire tra le istanze della classe DataTable, ogni caratteristica include un trigger comportamentale, che è responsabile per l'attivazione della funzione per quel caso particolare. Una caratteristica potrebbe apparire per gli attributi tavolo assegnato, come "scorrevole", o configurazioni colonna come "larghezza". Potrebbe anche avere più trigger, come ad esempio datatable-sort alla ricerca sia per l'attributo "ordinabile" tavolo o configurazione "ordinabile" la proprietà della colonna.

No More Accoppiamento

A partire da 3.5.0, Y.Columnset e Y.Column sono andato, e non si è limitati alla conservazione dei dati in Y.Record e Y.Recordset .

Definizioni di colonna sono ora memorizzati come un semplice array di oggetti, proprio come quello che passa nel DataTable columns attributo.

La ragione di questo cambiamento è che molte funzioni sono colonne specifiche, rendendo le definizioni di colonna un luogo naturale per configurarli. Ma la classe Colonna non dovrebbe includere gli attributi di funzionalità correlate a meno che tale funzione è richiesto. Tuttavia, le funzioni implementate come plugin non dovrebbe modificare direttamente le classi. Così come può una definizione di colonna sono sortable: true se la classe Colonna non ha un sortable attributo e il plugin non può aggiungere? Non c'era una buona risposta, quindi abbiamo (purtroppo) ha aggiunto gli attributi di funzionalità alla classe Colonna di base, permettendo loro di non fare nulla a meno che il plugin è stato aggiunto. Con così tante funzioni in attesa di DataTable che vogliono essere configurato nelle definizioni delle colonne, abbiamo deciso di rimuovere i wrapper di classe colonne in 3.5.0 per permettere colonne da definire con qualsiasi proprietà sono stati necessari. La giuria è ancora fuori su questo cambiamento, quindi siamo interessati nei commenti.

Sul lato dei dati delle cose, Recordset e Record sono stati tecnicamente funziona bene, ma con l'avvento della Y.Model e Y.ModelList in 3.4.0, c'era ora una grande opportunità per condividere le classi che erano suscettibili di essere utilizzati in altre parti del applicazione. Ciò significava, però, che DataTable avrebbe bisogno di essere disaccoppiato dalle sue classi di archiviazione dei dati perché il caso d'uso comune per i componenti quadro di AOL è quello di creare sottoclassi di loro con gli attributi e le API che specificamente incapsulare la logica di business.

Quindi, in 3.5.0, piuttosto che essere legato a Y.Record , record di dati sono memorizzati in casi sottoclasse modello. Per impostazione predefinita, DataTable creerà una sottoclasse modello per voi, personalizzati per i vostri dati, ma ora avete la possibilità di specificare la classe da utilizzare impostando il DataTable recordType attributo. Allo stesso modo, è possibile fornire la tabella data in un oggetto o modellista modellista-like.

Ora, se si condivide il modellista o modelle in tutta varie parti della vostra applicazione, le modifiche a nessuno di essi verrà automaticamente aggiornare la tabella.

Rendering personalizzabile

In 3.5.0, l'algoritmo di rendering è stato completamente riscritto, e adesso è molto più veloce e più configurabile rispetto al suo omologo 3.4.1. La guida alla migrazione e il manuale d'uso entrare nel dettaglio sulle varie opzioni di formattazione delle celle, ma un cambiamento importante vale la pena parlare qui è che l'intero algoritmo può essere sostituito con una semplice modifica di configurazione.

In linea con il passaggio al configurabili classi di archiviazione dati, DataTable ora deleghi le sue algoritmi di rendering a Y.View classi. In 3.5.0, di base, piatta DataTable ha attributi headerView , bodyView e footerView . Per impostazione predefinita, footerView viene disinserito, ma headerView è impostato su Y.DataTable.HeaderView , e bodyView è impostato su Y.DataTable.BodyView .

Quando un'istanza DataTable è render() ed, l'unico contenuto DOM stesso Widget è responsabile per il <table> e dei suoi figli immediati. Il rendering del contenuto di intestazione, il contenuto piè di pagina e le righe di dati è lasciato a qualsiasi classe View è fornito per l'attributo in questione.

L'impostazione predefinita Visite fornite in 3.5.0 sono abbastanza opzioni di configurazione delle colonne per gestire la maggior parte dei casi d'uso, ma se si hanno esigenze particolari per il rendering tabella o se si vuole ottimizzare il vostro iper-specifica implementazione, è possibile fornire le proprie classi Visualizza gli attributi notato in precedenza, e DataTable li utilizzerà invece.

Prossimamente

Il prossimo articolo andare più nel dettaglio le tecniche architettoniche DataTable, modelli sperimentali, e cosa sta per succedere nella prossima release.

Nel frattempo, assicuratevi di farci sapere nel forum yuilibrary.com , su Twitter , e nel YUI # canale IRC su Freenode, come vanno le cose nelle vostre applicazioni DataTable e quali caratteristiche stai più in attesa di.

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

YUI: Open Ore gio 3 maggio

30 aprile, 2012 alle 16:05 di Luke Smith | In Development | Nessun Commento

Armeggiare con DataTable

Per me, ci si sente come ogni altre Ore apertura è di circa DataTable, ma credo che non è vero. Quindi parliamo di DataTable!

In particolare, voglio parlare di due cose:

1. Consigli e trucchi con configurazioni di colonne e formattatori cellulari
2. Qual è veloce, ciò che è lento, e come ottimizzare le prestazioni DT

Sarà un sacco di codifica diretta su jsfiddle , anche se cercherò di avere alcuni esempi di cose prepped. Se c'è un esempio particolare che piacerebbe vedere, una questione di formattazione che si desidera rispondere, o in generale qualsiasi domanda DT altro o feedback, si prega di portarlo.

Registrazione

La registrazione è disponibile nel canale di YouTube YUILibrary , anche se la qualità non è venuto fuori molto bene.

Menzionato

• Proxy modellista mosca
• Più precisi aggiornamenti DOM da modifiche dei dati
• Personalizzato BodyView con la logica di rendering più semplice

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

Generalizzando Codice Attraverso programmazione funzionale

30 Aprile, 2012 alle 9:13 am da Giovanni Lindal | In Development | Nessun Commento

L'astrazione è una buzzword caldo, ma molte persone dicono di astrazione quando in realtà significa generalizzazione. Questi due concetti sono molto diversi. In realtà, si applicano alle estremità opposte del processo di codifica.

Molto è stato scritto su come astrazioni semplificare il lavoro di costruzione di software, durante la programmazione in grande. Purtroppo, astrazioni perdite, come dimostrato da Joel Spolsky e Jeff Atwood . Ciò non sorprende, data la definizione di astrazione: il processo di considerare qualcosa di indipendente dai suoi associazioni, attributi o accompagnamenti concrete. In altre parole, astrazioni ignorano i dettagli, e questo torna sempre a mordere noi.

Generalizzazione, invece, è utile quando focalizzando un problema specifico, cioè, la programmazione nel piccolo. Lo scopo di generalizzazione è per ottenere una soluzione di un problema utilizzabile per una più ampia classe di problemi connessi. Questo è il massimo in termini di riutilizzo del codice: costruire una volta e utilizzarlo più e più volte. Finché la generalizzazione avviene correttamente, non c'è pericolo di esso mancanza, se c'è sempre la possibilità di non prendere abbastanza lontano.

Ci sono molti modi per generalizzare codice. Questo articolo si concentrerà sulla costruzione di funzioni di ordine superiore, un particolare punto di forza dei linguaggi funzionali. Cominciamo con due esempi evidenti: map e reduce cui applicare una funzione ad ogni elemento di un insieme. Si tratta di generalizzare i concetti di generare una nuova collezione o valore, rispettivamente, da una raccolta esistente.

Dovrebbe essere possibile generalizzare map e reduce ulteriormente, a lavorare su una foresta, cioè, una raccolta di alberi, anziché soltanto un insieme di elementi. Il problema, tuttavia, è che il codice che deve saper recurses gli alberi vengono memorizzati. E 'un albero di array nidificati semplicemente, ad esempio, [1, [2, 3], 4] , o ogni nodo un oggetto da cui la matrice dei nodi figli devono essere estratti? Per reduce , si può passare in una funzione che estrae i bambini:

 Funzione reduceForest (radici, iniziali, funzionamento, bambini)
 {
	 ritorno Y.Array.reduce (radici, iniziale, la funzione (valore, root)
	 {
		 ritorno reduceForest (bambini (root), il funzionamento (valore, root), funzionamento, bambini);
	 });
 }

Per map , tuttavia, è più complicato, perché c'è anche la questione di ciò che il risultato dovrebbe essere simile. Un array nidificato può essere associato a un altro array nidificato, e un albero di oggetti può essere associato a un altro albero di oggetti, ma sostenendo sia allo stesso tempo renderebbe il codice piuttosto complicato. Sapere quando smettere di generalizzare è altrettanto importante quanto sapere quando andare avanti!

Siamo in grado di espandersi in una direzione diversa, però, perché ci sono molti tipi di collezioni, ma il codice sopra riportato richiede ai bambini di essere memorizzati in array. Abbiamo bisogno di generalizzare il concetto di iterazione.

Yui oop.js fornisce questa, nella funzione privata dispatch . Ecco la versione leggermente modificata utilizzata da gallery-funcprog :

 funzione di invio (azione, o)
 {
	 var args = Y.Array (argomenti, 1, true);
	 switch (Y.Array.test (o))
	 {
		 Caso 1:
			 tornare Y.Array [azione], si applicano (null, args).;
		 Caso 2:
			 args [0] = Y.Array (o, 0, true);
			 tornare Y.Array [azione], si applicano (null, args).;
		 default:
			 if (o && o [azione] && o! == Y)
			 {
				 args.shift ();
				 tornare o [azione], si applicano (o, args).;
			 }
			 altro
			 {
				 tornare Y.Object [azione], si applicano (null, args).;
			 }
	 }
 }

Questo è meravigliosamente generale. Funziona per ogni azione: la mappa, ridurre, filtro, array ecc vengono instradati verso Y.Array . Gli oggetti che implementano l'azione sono chiamati direttamente, consentendo lezioni individuali per ottimizzare le singole azioni. Tutti gli altri oggetti sono operati dalle versioni generiche di Y.Object (fornito da galleria-oggetto-extras ). Sharp lettori noteranno che l'ordine di iterazione per i membri degli oggetti non è definito, ma questo non ha importanza per map , reduce con gli operatori commutativi, filter , ecc (Usa Y.some a proprio rischio, però.)

L'opzione per gli oggetti per implementare le versioni personalizzate delle azioni porta ad un'altra generalizzazione: gallery-iterable-extras . Questo mixin implementa tutte le azioni per qualsiasi oggetto che fornisce l' iterator metodo. L'unico requisito è che iterator deve restituire un oggetto che espone next e atEnd . Ciò è particolarmente efficace per liste concatenate, dove ricerca indicizzata è O (n), ma potrebbe anche semplificare altre classi, ad esempio, Y.NodeList , perché uno quindi non è necessario implementare esplicitamente mappa, ridurre, filtri, ecc

Naturalmente, generalizzazione non deve essere presente complicato. Quando stavo scrivendo gallery-sort-extras , in primo luogo ho costruito questa funzione:

 Y.Sort.compareKeyAsString = function (key, a, b)
 {
     compareAsString ritorno (a [key], b [key]);
 };

Ma poi ho capito che avrei dovuto scrivere un separato compareKeyAsNumber , così invece mi generalizzata a:

 Y.Sort.compareKeyAs = function (f, chiave, a, b)
 {
     return f (a [key], b [key]);
 };

Dal sort richiede una funzione che richiede solo (a,b) , si deve usare Y.bind per fissare i primi due argomenti :

  sort (Y.bind (Y.Sort.compareAsKey, null, Y.Sort.compareAsString, key)) 

Finora, abbiamo considerato solo le funzioni che operano su funzioni. Si può anche costruire funzioni che le funzioni di ritorno. Un semplice esempio è una funzione per invertire l'ordine:

 Y.Sort.flip = function (f)
 {
     di ritorno della funzione (a, b)
     {
         ritorno f (b, a);
     };
 };

Speriamo che questi esempi di utilizzo di programmazione funzionale per generalizzare il codice vi spingerà a cercare situazioni in cui si può fare lo stesso nel proprio codice.

Circa l'autore: John Lindal ( @ jafl5272 su Twitter) è uno degli ingegneri di piombo costruire le fondamenta su cui Yahoo! APT è stato costruito. In precedenza, ha lavorato sul Yahoo! Publisher Network.

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

Aiutaci aiutare gli altri!

25 aprile 2012 alle 8:00 am da Dav vetro | In Development | 7 commenti

Una delle cose migliori di YUI è la nostra documentazione. E 'noto nella comunità per anni che la documentazione è una priorità assoluta per i nostri sviluppatori. Una delle nostre priorità è la documentazione di altre API eccezionale. Abbiamo sempre avuto documentazione di alta qualità, ma che viene fornito con un prezzo, il tempo.

Lo sapevi che puoi aiutarci in questo?

Tutta la nostra documentazione è disponibile nel nostro Github pronti contro termine e gli strumenti che usiamo per produrre questa documentazione sono disponibili per l'uso. Sì, è vero, tutto ciò che usiamo per fare la nostra documentazione è disponibile al momento. In questo articolo vi mostrerò come è possibile correggere la documentazione API e aggiornare un esempio per aiutare gli altri sviluppatori come te.

Questo articolo è su come modificare gli esempi esistenti, landing page e la documentazione API. Guarda lo screencast in fondo se siete più interessati a creare nuovi esempi da zero.

Di cosa hai bisogno?

Avete bisogno di una versione funzionante di Node.js (0.6.x o superiore è raccomandato), NPM (confezionato con nodo), Selleck il nostro strumento di documentazione personalizzata e YUIDoc il nostro strumento di documentazione delle API. Questi strumenti sono liberamente disponibili e molto facile da installare. Basta andare qui e scegliere il vostro ambiente di installare Node.js. Una volta installato, è possibile installare due nostri strumenti con questo comando:

 npm -g install selleck yuidocjs 

Una volta completata, è tutto pronto!

** È, naturalmente, hai bisogno di git installato, dispone di un conto Github e hanno già sborsato il repo yui3

Dove le cose vivono

Tutti i nostri esempi sono conservati nel nostro albero fonte principale, ciò rende più facile associare un esempio con il codice a cui appartiene. In questo esempio, lavorerò con i DragDrop esempi e documentazione API.

La pagina di destinazione principale e file di esempio si trovano sotto yui3/src/dd/docs . Tutti i documenti API vengono analizzati dalle prime file di origine (ci arriveremo in che in un bit).

Vedere un esempio reso

La parte più difficile di qualsiasi esempio, è vedere come appare una volta che è pronto. Questo è dove Selleck entra in gioco. Selleck ha una "modalità server" che si può sparare e vedere i nostri esempi "analizzato e caricato". Accensione Selleck "modalità server" è molto semplice:

 cd yui3/src; selleck --server 

Questo stamperà il seguente alla console:

 [info] Selleck is now giving Ferrari rides at http://localhost:3000 

Ora visitare http://127.0.0.1:3000 nel tuo browser della scelta e si dovrebbe vedere la pagina principale Selleck visualizzazione di una lista di tutti i componenti che si trovano sotto la src directory.

Se non si vuole Selleck di associarsi alla porta 3000, è sufficiente aggiungere una porta al comando sopra ( selleck --server 5000 )

Uno dei vantaggi dell'utilizzo Selleck in modalità server è che non è necessario riavviare il server (a meno che non si aggiungono nuovi file JSON per nuovi esempi) per visualizzare le modifiche. Basta aprire un file, modificare, salvare e ricaricare! È così facile!

Fissaggio documentazione API

Tutta la nostra documentazione delle API viene analizzato direttamente dai nostri file di origine yui3/src/dd/js con
YUIDoc . Questo rende la loro lettura nel file sorgente un po 'difficile (a meno che non si possono analizzare i tag JSDoc e la sintassi Markdown nella tua testa). Fortunatamente YUIDoc ha anche una modalità server per aiutarvi in questo. L'attivazione della modalità server di YUIDoc è semplice come Selleck di:

 cd yui3/src; yuidoc --server 

Questo stamperà alcune informazioni di debug YUIDoc termina con:

 info: (server): Starting server: http://127.0.0.1:3000 

Ora visitare http://127.0.0.1:3000 nel tuo browser della scelta e si dovrebbe vedere l'elenco pagina principale YUIDoc tutta la analizzato API docs.

Se non si vuole YUIDoc di associarsi alla porta 3000, è sufficiente aggiungere una porta al comando sopra ( yuidoc --server 5000 )

Modalità server YUIDoc le opere di un po 'come Selleck in che non è necessario riavviare il server per visualizzare le modifiche. YUIDoc di analisi sarà tutto il codice sorgente di ogni caricamento della pagina e vi mostrerà la versione aggiornata di API docs. Basta aprire un file, modificare, salvare e ricaricare! È così facile!

Cose da ricordare

Alcune cose da ricordare quando si lavora su qualcosa che si desidera contribuire:

• Lavorare sempre in un ramo git checkout -b mydocpatch
• Spingere alla filiale git push origin mydocpatch
• Inviare la richiesta Pull dal vostro ramo
• (Opzionale) Se sei a tuo agio con git, si consiglia di lavorare contro yui/yui3 's branch "live-docs"

Cosa fare dopo che avrò aggiornato cose?

Come ogni altra cosa in YUI, una volta aggiornare i file, semplicemente ci impegniamo ed emettere una richiesta di pull come al solito. Uno dei nostri sviluppatori verificare le modifiche e sia unirli o dare qualche feedback.

Quante volte sono cose aggiornate sul sito?

La nostra distribuzione del sito attuale è molto facile, spesso ci distribuire a yuilibrary.com almeno una volta alla settimana. A volte abbiamo anche spingere tutti i giorni! Quindi, prendi le tue modifiche e ridare alla comunità!

Ulteriori informazioni

YUI Ingegnere Luke Smith mettere insieme il cast seguente schermata che mostra come creare un nuovo esempio da zero. Date un'occhiata e altri video su sul nostro canale YouTube .

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

YUI: Orario di apertura gio aprile 26th

23 Aprile, 2012 alle 10:30 pm da Luca Smith | In Development e orari di apertura | Nessun Commento

Code Review: Foto Near Me

In un recente articolo di Eric F si riferisce a parte del suo esercizio per aggiungere YUI al lato server del suo progetto app, foto vicino a me. Forma breve: fin qui, tutto bene.

E 'stato un po' che abbiamo fatto una buona recensione stile vecchio codice, e questo mi sembra un candidato perfetto per questo. Lato server YUI, App quadro, desktop e considerazioni mobili, progressive enhancement. Un sacco di take away bene qui.

Registrazione

La registrazione è disponibile nel canale di YouTube YUILibrary .

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

Uso dei componenti YUI vostra applicazione sul server

23 Aprile, 2012 alle 03:36 di Eric Ferraiuolo | In Development , le implementazioni YUI | 5 commenti

Per il mio primo sprint 3.6.0 sviluppo sto scrivendo (e indicando con l'esempio) come sviluppare un'applicazione utilizzando YUI sul client e server, che funziona sia sul desktop e dispositivi mobili. Codice di condivisione e il riutilizzo FTW! Per avviare questo processo, ho voluto costruire qualcosa che prima con le strategie di sviluppo che vogliamo promuovere. L'ho fatto e voglio riferire in su la mia prima esperienza in esecuzione su YUI Node.js (spoiler: è stato fantastico!)

Foto Near Me , un'applicazione che vi mostra le foto interessanti vicine alla posizione corrente, è un progetto che ho iniziato quasi un anno fa per il cibo per cani quadro YUI App , mentre Ryan Grove e io stavamo scrivendo. Ho tenuto l'applicazione aggiornata con le ultime modifiche e integrazioni al Quadro App, compreso l'uso della Y.App , la nuova componente nel quadro App. Foto Near Me è sempre stato un client-side app solo fino ad ora!

Il mio piano era quello di alimentare le foto nelle vicinanze, i server utilizzando Node.js Express.js e YUI, e ho fissato due obiettivi: condividere oggetti del modello di app e condividere le sue Manubri modelli tra il client e server. Grazie a Glass Dav che ha messo in una tonnellata di sforzo per rendere YUI eseguito su Node.js in modo intuitivo e senza soluzione di continuità, sono stato in grado di realizzare facilmente questi obiettivi dopo diverse ore di refactoring l'applicazione. Sono stato piacevolmente sorpreso che il mio primo tentativo istanziare uno degli oggetti del modello server-side e chiamando il suo load() metodo, che recupera i dati da YQL, proprio frickin 'ha funzionato!

Foto Near Me rende ora lo stato iniziale per una richiesta sul server quindi giù le mani il controllo al client-side Y.App esempio. Da lì, nei browser moderni, che può utilizzare Storia HTML5, il routing, recupero dati e il rendering a pagina verrà effettuata sul lato client, mentre i vecchi browser eseguirà la pagina viene caricata completi gestiti dal server. Il tempo dalla richiesta di vedere le foto è stata drasticamente ridotta, è stato particolarmente evidente sul mio iPhone durante l'aggiornamento della pagina.

Essere in grado di utilizzare il codice esattamente lo stesso per i modelli e modelli tra il client e il server fa seguendo le migliori pratiche di progressive enhancement molto più facile da implementare.

Guarda le foto nelle vicinanze:
http://photosnear.me/

E la sua fonte:
https://github.com/ericf/photosnear.me

Guarda il mio esauriente tutorial sulla creazione di applicazioni con YUI che utilizzerà Foto Vicino a me come esempio per descrivere e mostrare in dettaglio come utilizzare YUI sul server e client per creare applicazioni che girano nel browser desktop e mobile, seguendo le migliori pratiche di progressive enhancement.

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!

Migrazione da 2 a YUI YUI 3: A Case Study

23 Aprile 2012 alle 9:26 am da Giovanni Lindal | In Development | 2 commenti

Quando mi sono seduto a costruire la versione 3 di YUI Layout di pagina , sapevo che sarebbe stato un grosso lavoro. Anche se la versione YUI 2 era sulla sua terza incarnazione, il codice era ancora un pasticcio. Il disegno originale, semplificando enormemente il disastro prestazioni della seconda incarnazione, ha chiesto solo layout fila-based, ma allora qualcuno aveva bisogno di un layout basato su colonna, e ne avevano bisogno veloce, così invece di refactoring del codice pulito, ho duplicato e riscrisse solo il motore di layout. Inoltre, sapevo che l'unico modo per convincere la gente a migrare dalla versione 2 alla versione YUI 3 YUI sarebbe quella di mantenere esattamente la stessa API nella versione 3 YUI, in modo che nessuno avrebbe dovuto riscrivere il codice. A peggiorare le cose, la YUI versione 2 era un oggetto globale che automaticamente istanziato quando lo script caricato, in modo il codice dell'applicazione potrebbe configurare e sottoscrivere gli eventi prima domready. La cosa peggiore implicazione di questo è che l'oggetto iniziale assunto una fila-based layout, e poi, domready, se una colonna layout basato su è stato rilevato, l'oggetto a sua volta sostituito in silenzio, la copia delle impostazioni dal vecchio oggetto! (La riga e la colonna versioni condiviso gli stessi oggetti evento, in modo che i sottoscrittori non sono stati influenzati.)

Con tutto questo da considerare, la prima cosa che feci fu di ignorare tutto perché volevo ottenere la versione corretta YUI 3. Ero soddisfatto con l'API di base, ma le due copie e la commutazione silenzio sulla domready doveva andare. Ispirato dall'architettura 3 Plugin YUI, ho deciso che la soluzione ideale sarebbe quella di avere una sola classe che ha rilevato il tipo di layout e ha usato il motore di layout corrispondente. Il Loader YUI sarebbe nemmeno mi permette di caricare il motore di layout su richiesta! Ci sono voluti un paio di settimane per distruggere i due YUI 2 classi e unirli in una singola classe con plugin, ma il risultato era pulito e (finché non guardare troppo da vicino il codice nel plugin dei motori di layout) la semplice .

Ora è arrivata la parte più difficile: come rendere questo un rimpiazzo per la versione 2 YUI. Le applicazioni che lo utilizzano ancora un sacco di YUI 2 del codice, e questo non può fare riferimento Y , in modo da YAHOO.APEX.PageLayout doveva essere definita, doveva essere creato quando lo script caricato e si è dovuto esporre tutte le funzioni necessarie e eventi firme. Per confondere ulteriormente le cose, YUI 3 firme eventi sono fondamentalmente diverse da YUI 2 firme eventi.

C'era anche un altro grave complicanza: YUI 3 non piace oggetti globali. Tutto ciò che è normalmente limitato alla Y sandbox creata da YUI().use() .

Il primo passo è stato quello di rompere la sandbox memorizzando l'istanza di Y.PageLayout in YUI.SATG.prototype.layout_mgr . (Creando un'istanza di YUI.SATG , ogni sandbox inizia con gli stessi valori iniziali e possono essere tranquillamente modificare Y.SATG senza influenzare altre sandbox. Naturalmente, sovrascrivendo Y.SATG.layout_mgr sarebbe una cattiva idea, ma non vi è altra roba in questo oggetto, anche.)

Rompere il sandbox non è qualcosa da fare alla leggera, però. Il problema più drammatico è che instanceof non funziona su oggetti passati tra le sandbox. Questo è disastroso per Y.PageLayout.elementResized() , in quanto l'argomento, un'istanza di Y.Node , è probabile che provengono da una sandbox diversa da quella in cui Y.PageLayout è stata creata un'istanza. Fortunatamente, YUI 3.5.0 passa dal instanceof Y.Node ad analisi per la _node membro!

Il passo successivo era quello di definire YAHOO.APEX.PageLayout (ma solo se YAHOO esisteva già, ovviamente). Questo oggetto è risultato essere molto sottile, dato che aveva solo agire come un relè. Memorizza i riferimenti alle funzioni di Y.PageLayout , tra cui un paio di rinomina e le istanze di YAHOO.util.CustomEvent .

Il passo finale è stato quello di sottoscrivere gli eventi da Y.PageLayout , rigenerare i dati, e il fuoco gli eventi corrispondenti YAHOO.APEX.PageLayout . Ad esempio:

 page_layout.on ('beforeResizeModule', function (e)
 {
	 YAHOO.APEX.PageLayout.onBeforeResizeModule.fire (e.bd, e.height, e.width);
 });

Spero che questa panoramica delle sfide che ho dovuto affrontare ti ispiri, o almeno sembrano rendere il compito meno arduo, quando a migrare verso YUI 3.

Circa l'autore: John Lindal ( @ jafl5272 su Twitter) è uno degli ingegneri di piombo costruire le fondamenta su cui Yahoo! APT è stato costruito. In precedenza, ha lavorato sul Yahoo! Publisher Network.

Trova le conversazioni: bloglines | technorati

Condividi ed estendere: Segnalibro con Del.icio.us | Digg it! | reddit!