Yahoo! User Interface Blog (YUIBlog)

YUI 3.4.0 Preview Release 3 jetzt erhältlich auf EUR

Die YUI-Team hat gerade die letzte Entwickler-Sprint für die 3.4.0 Version fertig gestellt. Zu dieser Zeit betrachten wir den Code funktional vollständig. Wir planen unseren nächsten Sprint die Fokussierung auf unsere letzte Runde der Tests und die Schaffung von mehr Beispiele und Dokumentation zu verbringen. Wir haben einen FC geschrieben (funktional vollständig) an die Gemeinde EUR für Exploration und Feedback zu bauen. Sie können auf dieses Release auf http://yui.yahooapis.com/3.4.0pr3/build/yui/yui-min.js .

Es gibt einige besondere Bereiche der Bibliothek, wo wir uns freuen, Feedback aus der Community haben würde:

• Loader hat ein wichtiges Update für 3.4.0 hatte. Wenn du tust Manueller Einzug Spezifikationen sind über use("*") oder nutzen Sie Submodul Konfigurationen, würden wir uns sehr freuen Sie versuchen, Ihren Code mit dem neuen Loader sicher sein, wir sind richtig Umgang mit allen Anwendungsfällen. Für weitere detaillierte Informationen zu den Loader Änderungen in dieser Version, beziehen sich auf die Blog-Eintrag beschreibt Loader 3.4.0 Änderungen .
• Kalender-und Panel sind voll funktionsfähig und bereit für Entwickler Verwendung.
• Grafik:. Es gab ein paar API-Änderungen, die keine experimentellen Code auf der Grafik-API in der PR2 Freisetzung verteilt geschrieben auswirken wird getShape() wurde umbenannt addShape() . Es wurden auch mehrere Attribut Ersatz.
• Transition: Native Übergänge sind nun in Firefox unterstützt.
• WidgetButtons wurde als neue Widget-Erweiterung, mit der Sie CSS-styled Schaltflächen in der Kopf-und Fußzeile jedes Widget, das Standard-Modul-Unterstützung implementiert platzieren können freigegeben.
• Widget-Modalität und Widget-AutoHide Plugins, Erweiterungen umgewandelt worden.
• Widget: Unterstützung für destroy (true), die zu entfernen und zerstöre alle untergeordneten Knoten (nicht nur die boundingBox und Contentbox) innerhalb des Widgets boundingBox enthalten. destroy () wird seine gegenwärtige Verhalten aufgrund der potenziell hohen Laufzeit-Kosten für die Vernichtung aller untergeordneten Knoten. Wenn Sie Widgets in Ihrer Anwendung oder zu vernichten sind ein benutzerdefiniertes Widget-Entwickler, würden Ihre Hilfe bei der Erprobung dieses Wandels gewürdigt werden.
• ScrollView unterstützt nun auch vertikale Paging, enthält eine Liste scrollview-Plugin, um CSS-Klassennamen zur sofortigen Liste Elemente hinzuzufügen, sowie mehrere Fehlerbehebungen und Refactoring
• App-Framework: Wir erweitern möchten ein herzliches Dankeschön an alle Entwickler in der Community die sich die Zeit zu Testfahrten mit dem neuen App Framework genommen haben. Wir haben sehr gutes Feedback im Anschluss an die Veröffentlichung PR2 empfangen. Bitte fahren Sie fort, um diese Komponenten zu erforschen und senden Sie uns Ihre Beobachtungen und Anregungen.

Sie können zusätzliche Informationen über den Inhalt dieser Pressemitteilung erhalten mit der Durchsicht der Geschichte Rollup und die vollständige Liste der Tickets in PR3 angesprochen . Bitte reichen Sie keine Anfragen wegen Erweiterungen, Fehler und Rückschritte in der Ticket-Datenbank auf YUILibrary.com .

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!

YUI: Öffnungszeiten Do. 28. Juli

Y.Calendar wird 3.4.0 kommenden

Kalender ist eine unserer beliebtesten Widgets in der YUI-2-Familie, und es ist ihr Debüt auf der YUI-3-Architektur in 3.4.0. Allen Rabinovich ist die Komponente, Inhaber und Autor werden und auf den Anruf Wiedereinführung uns zu diesem alten Liebling zu sein, zeigt einige neue Ansätze, um Probleme durch 2.x Kalender konfrontiert. Ich bin besonders über die Unterstützung für die Internationalisierung aufgepeppt, aber die neue Rendering-Regeln sind auch ziemlich faszinierend.

Komm rein, und bringen Sie Ihre Datumsauswahl, Event-Kalender, Import-aus-iCal-und-Make-Pfannkuchen Fragen und Feature Requests mit Ihnen, wie wir das Fleisch jetzt und zukünftig Y.Calendar . (Nein, es wird nicht importieren iCal, aber wenn jemand will, um eine Galerie-Modul zu erstellen, dieses Tier zu zähmen, es gibt sicher ein YUIConf Richtige sein für Sie drin ;))

Wir sind wieder zurück zu unserer gewohnten Zeit in dieser Woche, so dass wir Ihnen in Verbindung um 10 Uhr PDT sehen.

Zeit & Details

Wir werden Online von 10.00 bis 11.00 Uhr PDT am Donnerstag. Die Verbindungsdaten sind die gleichen wie immer.

1. Wählen Sie sich in 1-888-371-8922 (Skype funktioniert gut für Nicht-US-Teilnehmer *)
2. Geben Sie den Teilnehmer-Code 47188953 #
3. Join the Screen-Sharing-Sitzung (dies wird Sie auffordern, die Adobe Connect-Plugin zu installieren, wenn dies Ihre erste Mal benutzen)

Hinweis: Da es eine offene Konferenz Linie ist, bitten wir, dass Anrufer ihre Leitungen stumm zu schalten, wenn sie nicht an einer aktiven Diskussion teilnehmen.

* - Wenn Skype ist keine Option, mailen Sie mir oder fangen mich (ls_n) im IRC-Channel # yui auf Freenode für eine lokale Nummer.

Aufnahme

Vielen Dank an alle für den Aufruf in! Die Online-Aufzeichnung der Sitzung ist nun verfügbar.

Die hohe Qualität, iPhone / iPad kompatibel, herunterladbare Aufnahme ist hier .

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!

YUI: Öffnungszeiten Do 21. Juli

Eine DataTable-Update und Galerie-Schaukasten

Das 3.4.0 Release-Zyklus ist zu Ende und wird mit allerlei tollen Funktionen verpackt werden, aber deutlich zu sprechen, hat DataTable nicht so viel Entwicklung Fokus bekommen wie es sein sollte. Es wurden einige Fehler behoben, aber, und eine ganze Menge Planung für die Veränderungen, die in 3.5.0 ausgerichtet sind, und ein toller Start für gesellschaftliches Engagement mit seiner Entwicklung.

Wir wissen, dass DataTable ein unglaublich wichtiger Widget für viele Kunden ist, so verstehen wir die Kosten für die Verzögerung der Entwicklung fokussiert. Diese Öffnungszeiten wird ein Update auf das, was Arbeit ist immer getan sein für 3.4.0, 3.5.0, was für Planung, sowie eine Einführung in die großartige Arbeit, die damit begonnen, sprießen in der Galerie, um Funktionen hinzuzufügen und Beheben von Fehlern für DataTable (und ist seine Familie zu unterstützen Klassen).

Wir werden online sein eine Stunde früher in dieser Woche zum Wohle der Eamon Brosnan (aka, Mosen aus # YUI), die eine Reihe der Galerie Patches werden wir uns dann über zur Verfügung gestellt hat. Ansonsten müssen wir andere # yui Bewohner und Anbieter Galerie zeigen ihre Waren an. Wenn Sie ein DataTable-Lösung oder unfertigen Sie freigeben möchten, lassen Sie es mich wissen, damit ich blockieren kann den Zeitplan, um alles (ls_n in # YUI oder passen Twitter ).

Zeit & Details

Wir werden Online von 09.00 bis 10.00 Uhr PDT am Donnerstag. Die Verbindungsdaten sind die gleichen wie immer.

1. Wählen Sie sich in 1-888-371-8922 (Skype funktioniert gut für Nicht-US-Teilnehmer *)
2. Geben Sie den Teilnehmer-Code 47188953 #
3. Join the Screen-Sharing-Sitzung (dies wird Sie auffordern, die Adobe Connect-Plugin zu installieren, wenn dies Ihre erste Mal benutzen)

Hinweis: Da es eine offene Konferenz Linie ist, bitten wir, dass Anrufer ihre Leitungen stumm zu schalten, wenn sie nicht an einer aktiven Diskussion teilnehmen.

* - Wenn Skype ist keine Option, mailen Sie mir oder fangen mich (ls_n) im IRC-Channel # yui auf Freenode für eine lokale Nummer.

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!

Next-Gen YSlow angetrieben von YUI

Ein paar Wochen angekündigt, Yahoo! für Mobile YSlow bei Velocity 2011 , womit sich die Macht der YSlow Performance-Analyse, um die mobile Welt.

YSlow for Mobile arbeitet als Bookmarklet , die es ermöglichen, auf andere Browser als laufen Firefox (als Add-on) oder Chrom (als Verlängerung) .

Die YSlow Architektur wurde teilweise neu gestaltet, um zu arbeiten plattformübergreifend und YUI war der wesentliche Faktor in Sandbox machen, Cross-Browser-Abstraktion und einfachen Zugang YQL möglich.

Sandbox

Um auf einer Seite, ohne sich mit Performance-Analyse und ohne Unordnung mit der Seite selbst eingebettet werden, ist YSlow ein Bookmarklet, die JavaScript und CSS spritzt in jede Seite durch Ausschöpfung des Potenzials von YUI Sandbox:

Bookmarklet URL:

 javascript: (function (y, p, o) {
     p = y.body.appendChild (y.createElement ('iframe'));
     p.id = 'YSlow-Bookmarklet';
     p.style.cssText = 'display: none';
     o = p.contentWindow.document;
     o.open (). write ('
         <head>
         <Body onload = "
             YUI_config = {
                 win: window.parent,
                 doc: window.parent.document
             };
             var d = document;
             d.getElementsByTagName (\ "Kopf \ ') [0]
                 . AppendChild (
                     d.createElement (\ 'script \')
                 ). Src = \ 'http://d.yimg.com/jc/yslow-bookmarklet.js \' "
         >
     ');
     o.close ()
 } (Dokument))

Der obige Code:

• erzeugt ein leeres iframe;
• hängt es an der Seite Körpers;
• versteckt den iframe *;
• bekommt seine Fenster-Handler;
• schreibt in seinem Inhalt den Körper des iframe;
• Dieser Körper ist leer, hat aber eine onload Ereignis
• das onload Ereignis definiert, wie YSlow JS injizieren:
  • setzt YUI_config , so win und doc zeigt auf die Seite, die analysiert werden window und document bzw.
  • dynamisch injiziert YSlow URL, indem Sie eine script -Element in der iframe- head

* Der iframe wird durch die Zeit alle Vermögenswerte YSlow Präsentation geladen werden angezeigt

Das wird ein iframe in die Seite, die analysiert platzieren. Dies wird als iframe einer Sandbox-Umgebung zu agieren und wird innerhalb von YSlow es aufzuhalten. Da der iframe wird dynamisch erstellt, ohne die src -Attribut, wird sie haben Zugriff auf ihre Muttergesellschaft (die Seite, die analysiert werden), weil es keine Same Origin Policy Verletzung dort geschieht.

Die YUI_config Objekt ist praktisch, weil es setzt win und doc den IFRAME Muttergesellschaft (die Seite, die analysiert werden), damit jede neue YUI Instanz wird auf das übergeordnete Dokument standardmäßig Verdrahtung gebunden werden alle Anrufe zu Y.all und Y.one durch Y.config.win oder Y.config.doc aus dem YUI use Rückruf.

YSlow Die Präsentation wird durch den iframe gehandhabt window und document verweist, so dass der YSlow Haupt-Skript, um das Markup rendern sowie holen Sie das externe CSS innerhalb dieses iframe ohne in Konflikt mit der übergeordneten Seite der Stile. YSlow scannt die übergeordnete Seite, um alle Komponenten (Bilder, Skripte, Links, Hintergrund-Bilder, Flash, etc.) für die spätere Performance-Analyse erforderlich zu bekommen. Dies wird durch den Zugriff getan Y.config.win und Y.config.doc , da sie zu der übergeordneten Seite verweisen.

Cross-Browser-Abstraktion

Als ein Bookmarklet, wird YSlow for Mobile soll auf jedem Browser * zu arbeiten. YUI abstrahiert Cross-Browser-Probleme durch Normalisierung Browser-Unterschiede, was zu einem sauberen, leicht zu lesen und wartbar Codebasis.

YSlow wurde nicht in vollem Umfang zu YUI 3 portiert - nur der Controller-Schicht (aus dem kommenden App-Komponente) für jetzt - aber immer noch, alle DOM-Manipulation und Event-Handling werden durch die getan node und event -Module. In zukünftigen Versionen planen wir weitere Features, um YSlow YUI 3 zu portieren.

* Nicht alle Browser werden derzeit unterstützt

YQL

YSlow Seiten analysiert, indem Sie die HTTP-Header für die Komponenten auf der Seite gefunden. HTTP-Response-Header sind nicht in der Seite verfügbar ist, müssen daher diese Komponenten erneut angefordert werden, um für YSlow erhalten die Antwort-Header-Informationen. Dies könnte durch eine Anforderung der Liste der URLs Komponente durch XMLHttpRequest (AJAX), aber leider aufgrund erreicht werden Same Origin Policy Einschränkung , ist dies nur möglich, wenn alle Komponenten in der gleichen Domäne wie die Seite, was sehr unwahrscheinlich ist sind.

Eine gemeinsame Workaround für Same Origin Policy Einschränkung wird mit JSONP, wo ein externer Server arbeitet als Proxy-Anforderung der Liste der Komponenten, URLs und Abrufen ihrer HTTP-Response-Header im Namen YSlow. Aufgrund der Popularität und YSlow jüngsten mobilen Performance-Analyse Bemühungen, erwarten wir ganz stark befahrenen für die YSlow for Mobile Bookmarklet. Um einen solchen Verkehr zu unterstützen, YQL war die skalierbare Lösung durch YSlow durch einen angenommenen offenen Datentabelle namens data.headers , die die Response-Header und Inhalte abruft, für eine bestimmte Liste von URLs, während die Identität des User-Agent, um sicherzustellen, den erwarteten Inhalt ist abgefragt.

Die Abfrage YQL Komponente macht die ganze Arbeit der Verwaltung YQL Anfragen während die Verwaltung JSONP Anfragen unter der Haube, so dass die YSlow Controller-Code wesentlich einfacher und leicht zu pflegen.

Künftige Erweiterungen: Neue YSlow for Mobile Interface

Zur Zeit der YSlow für Mobile User Experience ist die gleiche wie die Desktop-Erfahrung. Der Umgang mit einer langen Liste von Performance-Analyse-Daten ist nicht die beste Erfahrung auf kleinen Smartphone-Bildschirmen. Seit YUI auch abstrahiert Cross-Device Gesten , wird YSlow for Mobile einen brandneuen mobilen Schnittstelle in zukünftigen Versionen zu bekommen.

Performance Performance-Tool

YSlow für den mobilen Einsatz gemacht wurde sorgfältig angesichts ihrer Auswirkungen auf die Leistung der Ladezeit der Seite, die analysiert werden. Die YUI 3 Module auf YSlow verwendet wurden geprüft, um nur die benötigten Module zu YSlow so schnell wie möglich zu laden sind. Die YUI Loader-Seed-Datei und wurden nicht berücksichtigt , da alle notwendigen Module und Submodule wurden zusammen nach kombiniert Ryan Grove Performance Zen Tipps, die es ermöglichen, alles zusammen laden zu einem einzigen kleinen einzigen Antrag gestellt: YSlow-bookmarklet.js: 204KB, 66KB ( gzip), wo:

• YUI: 75KB, 27KB (gzip)
• YSlow: 129KB, 39KB (gzip)

Mehr über YSlow

Bleiben Sie up-to-date mit den neuesten Ankündigungen von YSlow:

• Der Besuch des neu gestalteten YSlow Seite bei getyslow.com
• Liking YSlow auf Facebook: facebook.com / getyslow
• Nach YSlow auf Twitter: twitter.com / getyslow

Über den Autor: Marcel Duran ist das Front-End-Lead für Yahoo! 's Exceptional Performance Team. Er hat in Web-Performance-Optimierung auf High Traffic Sites in Yahoo! Startseite und suchen Teams, wo er angewendet worden und erforscht Web-Performance Best Practices machen Seiten sogar noch schneller. Er ist jetzt auf YSlow und andere Performance-Tools Entwicklung, Forschungen und Evangelisation gewidmet. Sein Ziel ist es, das Web noch schneller zu machen als es sein kann, und glaubt, es gibt nicht so etwas wie "nur ein paar Millisekunden wird nicht weh tun".

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!

Graded Browser Support Update

GBS Änderungen

Spezifische Änderungen für dieses Update enthalten:

• Nicht mehr zuweisen Erfahrung Noten
• Nicht mehr der Verschreibung bestimmte Betriebssysteme (außer für die mobile)
• Hinzugefügt Abdeckung für Internet Explorer 9
• Hinzugefügt Abdeckung für Firefox 4. †
• Hinzugefügt Abdeckung für Firefox 5. †

Hinweise:

• Der Dolch, Symbol (wie in "Firefox 4. †") zeigt, dass die meisten langfristigen Nicht-Beta-Version in diesem Zweig-Level-Support erhält.
• Werden keine Hinweise auf iOS oder Android OS Gerätenutzung gegeben. Die Empfehlung ist, dass Sie die Geräte, die meisten Vertreter Ihrer Nutzerbasis für jedes Betriebssystem wählen sind.

Entfernen von Noten aus dem Browser Test Baseline

Diese Ausgabe des GBS Aktualisierung bedeutet eine Abkehr von unserer bisherigen Updates, dass wir weg sind von Mapping-Browser direkt an Erfahrung Sorten (zB "A-Grade" und "C-grade"). Statt vorzuschreiben, was User Experience angemessen ist, für die Browser konzentrieren wir uns auf Festlegung einer wirksamen Strategie, die Baseline-Test Testabdeckung maximiert und minimiert die Prüffläche werde konzentrieren. Zum Beispiel setzte der IE6 immer noch bedeutenden globalen Marktanteil Optionsscheinen Tests, aber die heutigen GBS ermöglicht die IE6 User Experience anders zu sein als der IE9 Erfahrung.

Entfernen Betriebssysteme aus dem Browser Test Baseline

Um das Testen zu straffen und Ressourcenbedarf zu minimieren, haben wir nicht mehr angeben, welches Betriebssystem auf sollte geprüft werden. Die einzige Ausnahme ist, wenn der Browser ist eng mit dem OS-Version, in diesem Fall verweisen wir auf die OS-Version und nicht die Browser-Version (zB "Safari iOS 4") gekoppelt. Dies erlaubt uns, die Testabdeckung auf Browser-Versionen zu konzentrieren, und minimieren Redundant Tests auf allen Plattformen. Probleme mit dem gleichen Browser-Versionen über unbedeutend sind, und in der Regel an übergeordnete OS Unterschiede, wie z. B. Schlüssel Handhabung und verfügbaren Schriften verwandt. Code, der bekannt ist, auf Cross-Plattform-Fragen berühren wird, sollte auf so vielen Plattformen wie möglich getestet werden, aber diese Tests in der Regel kann auf die spezifischen Probleme, anstatt läuft eine vollständige Regression Test aller Funktionen isoliert werden. Wir empfehlen Ausrichten Betriebssystem Tests Priorität mit Ihrem Kundenstamm.

Warum ist IE6 noch auf der Liste?

IE6 immer noch einen signifikanten Weltmarktanteil genug, um eine akzeptable verifiziert User Experience zu rechtfertigen. Ein weit verbreitetes Missverständnis, mit dem Progressive Enhancement Strategie war, dass, sobald ein Browser "C-grade", dass es "nicht unterstützt" wird, geht in der Tat, wenn es wirklich bedeutet, dass es die reinen HTML-Erfahrung geliefert werden soll. Jetzt, da wir nicht mehr verschreiben, welche Browser welche Erfahrungen erhalten, wird dieser nach links für Projekte zu entscheiden, auf ihre Nutzer und Ressourcen. Die GBS konzentriert sich auf die Angabe, welche Browser eine überprüfte nutzbare Erfahrung auf Faktoren wie Marktanteil und den Einfluss der Basis brauchen. Definieren, was "brauchbar" und folgende Einzelheiten akzeptabel Abbauwerte links für Teams zu entscheiden. Wir fördern noch eine einfache Progressive Enhancement -Modell, und entmutigen Projekte aus der Schaffung neuer Ebenen ohne Berücksichtigung der zusätzlichen Kosten in Entwicklung, Prüfung, Wartung und Ressourcen.

GBS-Prognose

Wir erwarten, dass die folgenden Änderungen im nächsten Update zu machen:

• Unterbrechen Sie Versicherungsschutz für Safari auf iOS 3.
• In Deckung für Webkit auf Android 3.
• In Deckung für Firefox 6.
• In Deckung für Safari iOS 5.

Das GBS-Archiv

• GBS-Update, 2010-11-03
• GBS Update, 2010.02.16
• GBS Update, 2009.10.16
• GBS Update, 2009.07.02
• GBS Update, 2009.01.28
• GBS Update, 2008.07.03
• GBS Update, 2008.02.19

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!

Die "MakeNode" Widget-Erweiterung

Anmerkung der Redaktion: Da dieser Artikel ursprünglich veröffentlicht wurde, die MakeNode Modul hat zur YUI Galerie veröffentlicht worden und erhielt einige Verbesserungen. Bitte beachten Sie die aktualisierte Artikel, Aktualisiert: Die "MakeNode" Widget-Erweiterung .

In meinem vorherigen Artikel, Ein Rezept für ein YUI 3 Anwendung , zeigte ich einen Weg zu benutzen Y.substitute als eine sehr grundlegende Vorlage Prozessor. Die Idee nahm das Leben von dort aus, mit Anregungen von den Leuten im IRC-Channel # yui, und ich machte es ein Widget-Erweiterung, die auf meiner Seite ist, genannt MakeNode . MakeNode ist keine generische Template-Prozessor und es ist nicht so gemeint ist. Auf der anderen Seite, wird es eng mit dem YUI integriert Widget Foundation Class, einschließlich className-und Event-Helfer und Internationalisierung. In diesem Artikel werde ich die Spinner Beispiel und ändern Sie es, die Richtlinien aus meinem vorherigen Artikel zu folgen und MakeNode verwenden. Die modifizierte Komponente Spinner ( JS , CSS , Sprites ) sowie ein Beispiel sind von meiner Website zur Verfügung. Links zu weiteren Ressourcen finden Sie am Ende dieses Artikels zu finden.

Erweitern Sie Ihre Komponente

Sobald MakeNode geladen wird, müssen Sie das Modul in Ihr gehören YUI().use() -Anweisung mit dem Namen 'makenode' . Dann, um Ihr Widget erweitern, listen Sie diese in das dritte Argument zu Y.Base.create() , wie folgt aus:

  Y.Spinner Y.Base.create = (
      'Spinner',
      Y.Widget,
      [Y.MakeNode],
      {
         / / Instanz-Mitglieder ...
      },
      {
          / / Statische Member
      }
 ); 

Sie können MakeNode entlang einer beliebigen Anzahl von geeigneten Erweiterungen für Widget, wie WidgetParent, WidgetChild, WidgetStdMode hinzufügen, fügt usw. MakeNode zwei geschützte Methoden, _makeNode und _locateNodes, und es wird von mehreren statischen Eigenschaften zu lesen, wenn gefunden.

Alle Mitglieder dieser Erweiterung sind entweder protected oder private, da sie dazu bestimmt sind, von der Komponenten-Entwickler und nicht das von der Implementierung über die Komponenten, die nicht mit ihnen belästigt werden sollte verwendet werden.

Definieren der Vorlage

Das erste, was Sie normalerweise tun wird ist, um die Vorlage für Ihre Komponente zu definieren. Für die Spinner, wird unsere Vorlage sein:

  _template: [
     '<input Type="text" title="{s input}" class="{c input}">',
     '<button Type="button" title="{s up}" class="{c up}"> </ button>',
     '<button Type="button" title="{s down}" class="{c down}"> </ button>'
 ]. Join ('\ n'), 

Das Standard-Template wird in der Regel genannt werden _TEMPLATE und erklärte, an den anderen statischen Eigenschaften der Klasse, wie ATTRS . MakeNode wird diese Vorlage benutzen, wenn nichts anderes ausdrücklich vorgesehen ist. Die Vorlage wird von einfachem HTML sowie eine Reihe von Platzhalter in geschweiften Klammern, jeder von einem einzelnen Zeichen (die Verarbeitung Code) gemacht, gefolgt von einem oder mehreren Argumenten gemacht. Die Platzhalter und was sie produzieren, sind:

• {@ attributeName} Konfiguration Attributwert

• {p propertyName} Instanzeigenschaft Wert

• {m methodName arg1 arg2 ….} Rückgabewert der Methode gegeben. Die Verarbeitung Code wird durch den Namen der Methode und einer beliebigen Anzahl von Argumenten getrennt durch ein Leerzeichen gefolgt. Strings müssen in doppelte Anführungszeichen eingeschlossen werden. Zahlen, boolesche Werte und null wird von Saite zu ihrer richtigen Datentypen konvertiert werden

• {c classNameKey} CSS className aus der erzeugten _CLASS_NAMES statische Eigenschaft

• {s key} -String aus dem strings -Attribut, mit key , als der Sub-Attribut.

• {? other placeholder } Erzeugt die Zeichenfolge checked , wenn das Ergebnis der Verarbeitung der Rest der Platzhalter ist wahr.

• {} jeder andere Wert wird genau wie behandelt werden Y.substitute tut.

Zum Beispiel, {@ value} wird zu übersetzen this.get('value') , während {p value} übersetzt, um this['value'] .

Die {m} Platzhalter ist ein wenig komplexer. Das erste Argument nach dem m Verarbeitung Code ist der Name der Methode und der Rest der Argumente, die alle durch Leerzeichen getrennt, die an die angegebene Methode übergeben werden. Diese Argumente können Zahlen sein, null , true , false oder Zeichenketten in doppelte Anführungszeichen eingeschlossen. MakeNode werden sie analysieren und wandeln sie in ihrer richtigen Typen, also {m myMethod 123.45 true “this is a string”} wird im Aufruf zur Folge this.myMethod(123.45, true, “this is a string”) , so dass die ersten beiden Argumente werden, um deren korrekte Datentypen konvertiert und die Zeichenkette Leerzeichen enthalten. Um eine doppelte Anführungszeichen, verwenden Sie \\" , die doppelten Backslash erforderlich ist, weil JavaScript in ein einziges interpretieren wird und verwirft es, bevor es zu MakeNode bekommt. Nur doppelte Anführungszeichen erlaubt sind, MakeNode verwendet keine eval() so der Parser ist begrenzt aber sicher. Alles andere als Zahlen, null , boolesche Werte und Zeichenketten in doppelten Anführungszeichen werden ignoriert.

Der {?} Platzhalter ist praktisch, um mit Checkboxen und Radio-Buttons verwenden. Es gibt die Zeichenkette “checked” in Abhängigkeit von der Wahrheitswert der Verarbeitungsanweisung Code, der folgt. So <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/> wird einen deutlichen Kontrollkästchen, wenn der getLength Methode liefert alles andere als Null. {?} wird eine der anderen Platzhalter akzeptieren, obwohl es nur Sinn macht mit den ersten drei.

Für die {c} Platzhalter, müssen wir haben ein _CLASS_NAMES Eigenschaft definiert.

Weitere Platzhalter können hinzugefügt werden, indem man sie in die MakeNode werden _templateHandlers Hash.

Die _CLASS_NAMES Eigentum

Zusammen mit dem ATTRS und _TEMPLATE statische Attribute, können wir definieren eine _CLASS_NAMES Eigenschaft, die auf ein Array von Strings zeigt. Jede dieser Zeichenfolgen wird verwendet, um eine className zu erzeugen. So _CLASS_NAMES: ['input'] die className produzieren wird “yui3-spinner-input” . Diese Klassennamen werden in einer Instanz-Eigenschaft gespeichert this._classNames . Die {c input} Platzhalter in der Vorlage oben wird ersetzt durch “yui3-spinner-input” .

Sie können die _CLASS_NAMES -Eigenschaft auf eine beliebige Anzahl von Klassennamen zu generieren, ob man sie in der Vorlage verwenden oder nicht. Sie können immer noch erreichen diese zusätzlichen Klassennamen von innerhalb this._classNames . Der className wird unter Verwendung des yui3 Präfix durch den Wert des gefolgt NAME statische Eigenschaft wandte Kleinbuchstaben, und dann die Zeichenfolge im gegebenen _CLASS_NAMES (das letzte wird nicht gedreht werden klein geschrieben), die alle durch Bindestriche getrennt sind. Die _classNames Hash enthält auch die Klassennamen für die boundingBox und der contentBox , die erste unter der "." Schlüssel und die zweite unter dem “content” -Taste. Widget tritt dem boundingBox die Klassennamen von den Werten der abgeleiteten NAME Eigentum der jede der Klassen in der Vererbung Kette, beginnend mit yui3-widget . MakeNode Läden in this._classNames nur das oberste className für die boundingBox .

Wenn eine Komponente mehreren Ebenen weg von Widget, wie SuperSpecialSpinner Erben von SuperSpinner die aus erbt Spinner , die aus erbt Widget, und wenn einer oder alle von ihnen haben _CLASS_NAMES Eigenschaften definiert, MakeNode Klassennamen wird für alle von ihnen produzieren und speichern sie in this._classNames . Sie müssen nicht auf jeder Ebene die Namen bereits in den vorangegangenen Stufen erklärt gehören. In der Tat ist es besser, dass Sie nicht da die Klassennamen auf jeder Ebene produziert wird den Wert des benutzen NAME Eigentum von diesem Niveau. So wird in SuperSpecialSpinner , {c input} wird immer noch dazu führen, “yui3-spinner-input” und nicht “yui3-superspecialspinner-input” und so wird es halten Sie Ihre CSS-Datei immer noch gültig.

Der Platzhalter {s}

Widget hat eine strings -Konfiguration Attribut definiert, obwohl es nicht mit einem beliebigen Wert initialisiert. Dieses Attribut soll Strings, die sichtbar (oder mittels Screenreader, um zu lesen) den Anwender liegen auf Halten. Es ist wichtig, dass Sie nie gehören sichtbaren Strings direkt in der Vorlage. Dies ist keine Forderung der MakeNode - es war noch nie so eine gute Idee überhaupt. Alle Strings, die durch angesehen oder gelesen werden, um den Benutzer sind, sollte immer in der platziert werden strings -Attribut. Die strings Attribut enthält einen Hash, wo jeder einzelne Text durch seinen Schlüssel befindet. Die Spinner-Komponente hat, die folgende Zeichenfolgen, die Sie in der Vorlage verwendet werden oben zu sehen.

  Streicher: {
     Wert: {
         Eingang: "Drücken Sie die Pfeil hoch / runter-Tasten für kleinere Schritten, page up / down für die großen Schritten."
         bis: "Increment",
         unten: "Dekrement"
     }
 }, 

Der beste Teil der dabei ist, dass Ihre Komponente in andere Sprachen können sehr leicht lokalisiert werden, indem Entwickler, die mit Ihrer Komponente. Beim Erstellen einer Instanz der Spinner, könnten Sie tun:

  var = new mySpinner Spinner ({Saiten: Y.Intl.get ('Spinner')}); 

Einstellen der Konfiguration Attribut strings auf diese Weise ersetzt die Standard- strings -Werte mit denen aus der Sprache Ressource Datei mit Hilfe des zuvor definierten Sprache. Die {s} Platzhalter greift die Saiten in der gespeicherten strings Attribut, entweder die Standard-oder diejenigen die übersetzten diejenigen, falls eingestellt. Die {s xxxx} Platzhalter ist in der Tat nichts anderes als eine Verknüpfung zu dem {@ strings.xxxx} Platzhalter. Allerdings kann der erste nur auf Saiten auf der obersten Ebene, während zum Beispiel {@ strings.xxxx.yyyy.zzzz} Ihnen erlauben würde, einen String tiefer zugreifen.

Mit _makeNode in renderUI

Wir verwenden die Vorlage, um das Markup für unsere Komponente zu erstellen. Dazu rufen wir die MakeNode _makeNode Methode, wie folgt aus:

  renderUI: function () {
     . this.get ('Contentbox') append (this._makeNode ());
 }, 

Dies wird in der füllen contentBox unserer Widget mit dem Markup aus der Verarbeitung der Vorlage. Die _makeNode Methode gibt eine Instanz von Y.Node , die angehängt oder eingefügt werden können oder einfach nur überall statt für die spätere Verwendung. Es gibt nicht einen String, produziert sie einen Node Instanz.

Die _makeNode Methode hat zwei optionale Argumente: ein Verweis auf eine Vorlage und ein Objekt in Platzhalter füllen, als Y.substitute tut. In diesem einfachen Spinner Beispiel gibt es eine einzige Schablone für die ganze abrufen kann aber auch andere Widgets Bruchstücke von mehreren Vorlagen zu verlangen. In diesem Fall würden Sie in der Regel rufen _makeNode ohne Argumente für den Hauptteil und rufen Sie es erneut mit verschiedenen Vorlagen, um in den zusätzlichen Teile zu füllen. Das Beispiel enthält diese renderUI Methode:

  renderUI: function () {
     var fieldset = this._makeNode ();
     this.each (function (item) {
         fieldset.appendChild (this._makeNode (MultipleTemplates.RADIO_TEMPLATE, item));
     }, This);
     this.get ('Contentbox') append (fieldset).;
 } 

Der erste Aufruf von _makeNode gibt einen Node -Instanz in der Variable gespeichert fieldset . Die Probe Komponente ist auch mit erweitert Y.ArrayList so dass die RADIO_TEMPLATE mit Werten aus den Elementen in dem Array Liste gespeichert, und die resultierenden Knoten angehängt dem aufgenommenen gefüllt wird fieldset bevor es schließlich auf die beigefügte contentBox . Die spezielle Platzhalter wie {@} oder {p} wird immer noch um die Attribute oder Eigenschaften in der Haupt-Objekt verweisen. Die verschachtelten Elemente verarbeitet werden ebenso Y.substitute würde.

Die Methode _locateNodes

MakeNode stellt weiterhin ein _locateNodes Methode, die versuchen, alle Elemente mit den Klassennamen in lokalisieren erklärt wird _CLASS_NAMES . Um bestimmte Elemente, die Sie beliebig viele className Schlüssel übergeben können finden, sonst _locateNodes versucht sie alle. Für jedes Element eines jeden className gefunden, _locateNodes erzeugt eine private Instanz-Eigenschaft mit dem Unterstrich-Präfix, indem der Name des Schlüssels und dem gefolgt “Node” -Suffix. So wird in unserem Beispiel Spinner, _locateNodes generiert die Eigenschaften _inputNode , _upNode und _downNode . Wenn mehrere Elemente die gleiche className haben, _locateNodes eine Bezugnahme auf die erste von ihnen zurück. Wenn ein Element nicht gefunden wird, wird keine Variable angelegt werden.

In der Spinner-Komponente verwenden wir _locateNodes nach dem Erstellen des Markups:

  renderUI: function () {
     . this.get (CBX) append (this._makeNode ());
     this._locateNodes ();
 }, 

Die _events statische Eigenschaft

Eine weitere Eigenschaft kann nach dem Vorbild der definiert werden _TEMPLATE und _CLASS_NAMES und das ist _EVENTS . _EVENTS wird eine Hash-up von Klassennamen Tasten, die jeweils eine Hash des Event-Typen und Methoden, um sie zu behandeln, zu enthalten. Es ist besser mit einem Beispiel erklären:

  _events: {
     '.': {
         Schlüssel: {
             fn: '_onDirectionKey',
             args: ((Y.UA.opera) "down"!? "Presse:") + "38, 40, 33, 34"
         },
         mousedown: '_onMouseDown'
     },
     '..': {
         mouseup: '_onDocMouseUp'
     },
     Eingabe: {
         Änderung: "_onInputChange '
     }
 }, 

_EVENTS ist ein Objekt (ein Hash) mit einer beliebigen Anzahl von Eigenschaften. Die Namen der Eigenschaften, das heißt, die Schlüssel des Hash, identifizieren die Elemente, deren Ereignisse werden wir zuhören. Es sind die gleichen Kennungen verwendet in _CLASS_NAMES . Es gibt zwei zusätzliche Sondertasten "." und ".." . Während die className-Tasten, um Elemente innerhalb der verschachtelten beziehen contentBox , die "." bezieht Schlüssel zum boundingBox selbst, während ".." bezieht sich auf das Dokument mit diesem Widget. Betrachten Sie sie als eine tun chdir Befehl, wenn an der sich boundingBox Ebene. Die _EVENTS Gegenständen verarbeitet wird, nachdem die renderUI , bindUI und syncUI Methoden aufgerufen wurden, so das Widget wird erwartet, dass bereits innerhalb des Dokuments Körper eingeführt werden, da sonst die ".." schlägt fehl.

Jeder der Einträge in _EVENTS ist eine weitere Aufgabe, die die Art des Ereignisses verwendet als Schlüssel und den Namen einer Instanz-Methode, damit umzugehen. _EVENTS , da eine statische Variable, hat keinen Zugriff auf this , sodass sie nicht nehmen eigentliche Funktion Referenzen, nur der Name des Ereignis-Listener-Methode. Einige Ereignistypen benötigen zusätzliche Argumente, wie die key -Ereignis. In diesem Fall anstelle der Bereitstellung den Namen der Event-Handler können Sie ein Objekt mit Eigenschaften zur Verfügung zu fn und args auf den Namen der Funktion und die zusätzlichen Argumente, zu halten, wenn erforderlich.

MakeNode verwenden Node.delegate bis zu den Ereignissen der verschachtelten Elemente zu hören, während es benutzen will Y.on , um auf Ereignisse aus der zuhören boundingBox und dem Dokument Körper. (Hinweis: Hören auf das key -Ereignis auf jedem verschachtelten Element funktioniert nur mit Version 3.4.0pr1 und oben, da Delegation der key .. Veranstaltung nicht zur Verfügung stand, bevor alle anderen Funktionen arbeiten mit früheren Versionen auch)

Die _EVENTS Erklärungen sind kumulativ, wenn Komponenten voneinander erben. Jede Klasse in der Vererbung Kette wird eine eigene _EVENTS Erklärung separat verarbeitet.

Die _ATTRS_2_UI statische Eigenschaft

Veranstaltungen in beide Richtungen gehen, von der Benutzeroberfläche auf das Bauteil und von der Komponente bis zur UI. Die erste von der Handhabung _EVENTS Eigentum. Dann gibt es die Ereignisse, die von Attribut-Wert Änderungen, die in der Benutzeroberfläche widerspiegeln müssen gefeuert. As I mentioned in the previous article, when there are any secondary effects from changing a configuration attribute, they should be handled by change event listeners, not by the optional setter method of the attribute, which should only deal with normalizing the value being set. The UI should reflect the state of the configuration attributes, first in syncUI , when being initialized and then on every attribute change event. For the latter, we need to attach an event listener, which we do in bindUI . Widget already provides a mechanism to make that simple, which I described in the comments to the previous article.

Widget uses the instance property _UI_ATTRS that contains an object with two further properties, SYNC and BIND . Each of these is an array listing the names of the configuration attributes to be initially synched and then listened to in order to keep the UI reflecting current values. Widget expects each of those entries to have a method associated with it, named after the attribute name prefixed by _uiSet with the first character of the attribute name converted to uppercase to have the method name in proper camel case. Thus, if "value" was listed in any of the _UI_ATTRS arrays (in either SYNC or BIND ), Widget would expect to find a _uiSetValue method. This method will receive two arguments, the value being set and the src of the change. This is the code for our Spinner _uiSetValue method:

 _uiSetValue : function(value, src) {
    if (src === UI) {
         zurück;
     }
    this._inputNode.set(VALUE, this.get(FORMATTER)(value));
}, 

All the uppercase identifiers you see in this piece of code correspond to string constants declared elsewhere, to allow the YUI compressor to do its job better. The method, basically, sets the value HTML attribute in the <input> box to the new value set, after being formatted. The reference to the textbox was provided by _locateNodes . The src argument is initially checked to see if set to the string value 'ui' . If this is so, no action will be taken. This is to avoid endless loops. If the user enters something in the input box, its value would go into the value configuration attribute which then would fire a valueChange event, which would get _uiSetValue called which, if unchecked, would then go and change the value of the input box, which would trigger the whole process again. Thus, in _uiSetValue , if we know the change comes from the UI, we do nothing and so break the loop. However, this requires another piece of code elsewhere. In the listener for the DOM event, when we set the configuration attribute, we use the third optional argument to set, like this:

 _afterValueChange : function(ev) {
    this.set(VALUE, ev.newVal, {src: UI});
 } 

It is up to us to ensure that changes coming from the UI are flagged thus and then check that same flag to avoid loops.

With all this said, I haven't yet mentioned the static property _ATTRS_2_UI mentioned in the heading of this section. As the comments in my previous article shows (through the blunders I made in them), making sure that all attributes affecting the UI are properly listed is somewhat messy. You should never initialize _UI_ATTRS from scratch since Widget already lists a whole lot of attributes and those would be lost. You have to concatenate new attribute names over the existing ones, which is somewhat hard to remember how to do it right. To make it simple, MakeNode will read from the static property _ATTRS_2_UI and do that concatenation for you. It will concatenate all such lists from each and every class in the inheritance chain so at each level each class can handle its own attributes. In Spinner, we have:

 _ATTRS_2_UI: {
    BIND: VALUE,
    SYNC: VALUE
}, 

MakeNode will accept both an array of names or a single attribute name, as in this case.

The question naturally arises, why two lists, one for binding the other for syncing? Quite often the SYNC array has fewer entries than the BIND list and this is because the template for the component might already have the very same default value as the configuration attribute and there is no need to do an initial syncing. So, if the default value for the value configuration attribute is an empty string and the <input> element in the template has no value attribute, then there is no need to sync them on initialization.

MakeNode will check for duplicate entries in any of these arrays. If any appear, it means that a class our component inherits from already handles this attribute and any new declaration would most likely overstep the _uiSetXxxx handler for it. Incidentally, MakeNode also checks for duplicate entries in _CLASS_NAMES , which can also cause conflict in some, though not all, circumstances. MakeNode will write a message to the log for any such error.

Abschluss

MakeNode provides a very simple template processor, with simple functionality that is highly integrated with the Widget foundation class. It also provides helper methods to create classNames to be used in the template and use those names to locate the nodes created. It also provides the means to hook into the events generated both by the UI and the component itself and associate each with a method. It does all these things, while taking care to respect the inheritance chain straight up to Widget and any level of classes you may define.

It does not provide for absolutely all possibilities, but covers a good range of them. Nevertheless, it does not preclude you from adding extra functionality. You might rarely have to write a bindUI or syncUI method if you use the glue provided by MakeNode, but you may do so, since MakeNode does not use them.

As a bonus to those who had the patience to read this far, I have also modified Anthony Pipkin's Button set of gallery components:

• button.js
• button.css
• button-group.js
• button-group.css
• background.png
• background-active.png
• icon-sprite.gif
• example

The API docs can be found here .

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!

YUI Loader und Änderungen für 3.4.0

In 3.4.0 we started the process of shifting some of Loader's logic around, to not only make it more performant, but to make it more robust and easier to use in other places (like on the server). We will be rolling out more changes in future revisions, but I wanted to take some time and explain what was changed, why it was changed and how it may impact developers. For the majority of use-cases, developers will notice nothing different, except that things are a little faster and their requirement downloads are a little smaller.

Seed File

The first thing I want to address is the YUI seed file. In previous versions of YUI, our seed file was very tiny and did not contain Loader or any of its meta-data. We've found that in the 90% use-case this was not as performant as we had hoped. The normal user includes the seed file then requests their modules, which in turn means that the seed needs to first fetch Loader, then calculate all of its dependencies, then fetch them all. We now feel that this extra http request is the wrong thing to do, so the new standard seed file contains Loader and its meta-data. Yes, this will make the initial request a little larger, but it will make the loading of modules that much faster since all of its meta-data requirements are now already on the page.

If you wish to use it the old way, you can just include the yui-base seed file instead. It contains everything that is needed to make YUI run in stand-alone mode plus it contains the ability to fetch Loader on demand. If you require even finer-grained dependencies, we have created a yui-core seed file that is exactly what the old yui-base seed was.

    /build/yui/yui-min.js //YUI Seed + Loader
    /build/yui-base/yui-base-min.js //Old YUI Seed with Loader fetch support
    /build/yui-core/yui-core-min.js //Old yui-base without Loader fetch support

It should be noted that these URLs are different than the previous URLs. Anyone that was using the yui/yui-base.js files need to repoint them to yui-core/yui-core.js . If you want the older way of loading the seed and fetching Loader, you would use the yui-base/yui-base.js seed file.

The other reasoning for this change is our roadmap for making YUI run in as many places as possible. The old seed file plus Loader in a single combo server request is all well and good if you have a combo server available in your application. But what about on the server? Or in an offline app on a mobile device? These places need to minimize file access while still getting the information they need.

Rollups

The next thing that we changed was removing rollups from the system and defaulting allowRollup to false in the Loader config. What does this mean to you? Well, hopefully nothing at all. Before I explain the impact of the change, let me explain the reasoning behind it. The primary reason is, again, performance, along with payload delivery. Take this example:

     Module A: requires event-a, event-b
     Module B: requires event-c, event-d

When you request both, the rollup logic prior to 3.4.0 used to determine that you should get the event rollup. Which actually meant that you were getting:

     event.a, event.b, event.c, event.d, event.e, event.f, event.g, event.h

You ended up with more on your page than you actually needed. By turning off the rollup support, YUI will now ask for only what you actually requested and nothing more. In most cases, you will not notice this . Module developers, may run into a situation where things that worked in the past may not work now. The reason for this is that they actually worked by accident before. Let me use a real world example: Dial .

In 3.3.0, Dial required this:

    requires: [
        'widget',
        'dd-drag',
        'substitute',
        'event-mouseenter', 
        'transition',
        'intl'
     ]

For the most part, Dial worked in 3.4.0, however keyboard support did not work. After doing some simple investigating, it turned out that the rollup support was actually requesting the entire Event rollup (which includes event-move and event-key). Without the rollup logic pulling in all of event, 3.4.0 Dial no longer had all of its requirements. Making Dial's requirements more specific and defining all of its actual dependencies properly makes it work as expected.

    requires: [
        'widget',
        'dd-drag',
        'substitute',
        'event-mouseenter',
        'event-move',
        'event-key',
        'transition',
        'intl'
     ]

For module developers, it is a best practice to make sure that your module requires exactly what it needs to function. Do not assume that an upstream module requirement is there. It's always better to make sure that you ask for what you need.

This also means that module requirements are more well defined. For example, datatype-date has Intl support built in. In previous versions you would access the Intl like this:

    Y.Intl.getAvailableLangs('datatype-date');

But since this module doesn't actually have a language (the datatype-date-format module does), this will fail. It needs to be more specific and actually ask for languages for the correct module:

    Y.Intl.getAvailableLangs('datatype-date-format');

Build File Explosion and Submodule Removal

After making this change, the next change we made was exploding the build directory and removing submodules from the core system. Submodule logic was not removed, only our meta-data structure was changed. This will provide backward compatibility for current installations.

Submodules in the core system caused a couple of issues that we needed to resolve. The first reason was performance. Each time Loader needed to calculate dependencies, it needed to walk the submodule/plugin structure of each module. Doing this thousands of times was hurting our performance during the Loader calculate routine. By removing support for submodules in the core system we saved tens of thousands of function calls and iterations.

Loader was changed so that if a use property in a module's meta-data defined more modules, it will use those modules instead of trying to load the original module. So, if you requested “ dd ” Loader would inspect “ dd “'s meta-data and see a use property that looks something like this:

    "dd-ddm-base,dd-ddm,dd-ddm-drop,dd-drag,dd-proxy,dd-constrain,dd-drop,dd-scroll,dd-drop-plugin"

In the core YUI seed file, we are also including what we are calling virtual rollups or aliases . These module definitions are exactly the same as the meta-data in Loader. This way you can include all the files exported from our Dependency Configurator and still use these rollups without having Loader present on the page. In future releases, we will be refining this approach even more.

After making this change, we then preceeded to explode our build files. In previous releases, the submodules determined the modules file path. Zum Beispiel:

    "dd": {
        "submodules": {
            "dd-drag": 
            // Module data
         }
     }

In 3.3.0 when you built “dd”, the file structure looked something like this:

    /build/dd/dd-drag.js
    /build/dd/dd-ddm.js
    /build/dd/dd-drop.js

With the build system exploded in 3.4.0, “dd”'s build files now look like this:

    /build/dd-drag/dd-drag.js
    /build/dd-ddm/dd-ddm.js
    /build/dd-drop/dd-drop.js

This allowed us to remove the “path” property from all of our module meta-data as well, saving file size and reducing the logic required to assemble the modules url paths.

If you are including a pre-configured combo URL, you must recalculate your URL when you upgrade.

The downside to this change is that if you are including a combo URL of modules to “prep” your page you can not just change the version number and upgrade. You will need to revisit the Dependency Configurator and generate a new URL with new module structure.

Die Zukunft

I will be continuing to refine, refactor and maximize every aspect of our Loader and Seed strategy. These first steps were needed to aid in future changes that need to be made for not only our client-side strategy but also our server, command-line and mobile device strategies as well.

Finden Gespräche: Bloglines | technorati

Teilen und zu erweitern: Lesezeichen mit del.icio.us | Digg it! | reddit!