YUI 3.4.0 Voorbeeld Release 3 nu beschikbaar op CDN

28 juli 2011 om 12:39 door George Puckett | In ontwikkeling | 4 Opmerkingen

De YUI team heeft zojuist de definitieve ontwikkeling sprint voor de 3.4.0 release. Op dit moment beschouwen we de code functioneel compleet. We zijn van plan om onze volgende sprint concentreren op onze laatste ronde van het testen en het creëren van meer voorbeelden en documentatie door te brengen. We hebben geplaatst FC (functioneel compleet) te bouwen aan de CDN voor de gemeenschap exploratie en feedback. U kunt deze versie op http://yui.yahooapis.com/3.4.0pr3/build/yui/yui-min.js .

Er zijn een aantal specifieke gebieden van de bibliotheek waar we graag feedback van de community hebben:

  • Loader heeft een belangrijke update voor 3.4.0. Als je aan het doen handmatige toevoer specificaties via use("*") of gebruik maken van submodule configuraties, zouden we het zeer op prijs probeer je de code in met de nieuwe Loader om zeker te zijn hebben we juist alle use cases behandelen. Voor meer gedetailleerde informatie over de Loader veranderingen in deze release, zie de blog post beschrijven 3.4.0 Loader veranderingen .
  • Kalender en Panel zijn volledig functioneel en klaar voor ontwikkelaars gebruik.
  • Graphics:. Er zijn een aantal API veranderingen die een experimentele code in die op de Graphics API verdeeld in de PR2 release zal van invloed zijn getShape() is omgedoopt tot addShape() . Er zijn ook een aantal attribuut vervangingen.
  • Overgang: Native overgangen worden nu ondersteund in FireFox.
  • WidgetButtons is vrijgegeven als een nieuwe Widget extensie die u toestaat om css-stijl knoppen te plaatsen in de kop-en voettekst van een widget die standaard module support implementeert.
  • Widget-modaliteit en Widget-Autohide plugins zijn omgezet naar extensies.
  • Widget: Toegevoegde ondersteuning voor te vernietigen (true) die zal verwijderen en vernietigen alle onderliggende nodes (niet alleen de BoundingBox en contentBox) vervat in BoundingBox van de widget. te vernietigen () zal haar huidige gedrag als gevolg van de potentieel hoge run-time kosten van het vernietigen van alle onderliggende knooppunten. Als u te vernietigen Widgets in uw applicatie of een aangepaste widget ontwikkelaar, zou uw hulp bij het testen van deze wijziging worden op prijs gesteld.
  • ScrollView ondersteunt nu verticale paging, is voorzien van een scrollview-lijst plugin om CSS classnames toe te voegen aan onmiddellijke lijst elementen, maar ook een aantal bug fixes en refactoring
  • App Framework: We willen een welgemeend dank aan alle van de ontwikkelaars in de gemeenschap die de tijd hebben genomen om te testen rijdt de nieuwe App Framework. We hebben uitstekende feedback naar aanleiding van de PR2 release. Ga door met deze componenten te verkennen en stuur ons uw opmerkingen en suggesties.

U kunt meer informatie over de inhoud van dit persbericht door de herziening van de Geschiedenis Rollup en de volledige lijst van tickets aan bod in PR3 . Gelieve in te dienen geen verzoeken om verbeteringen, bugs en ​​regressies in het ticket database op YUILibrary.com .

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

YUI: Openingsuren do 28 juli

25 juli 2011 om 22:56 door Luke Smith | In Ontwikkeling , Open Uur | 2 Commentaren

Y.Calendar komt naar 3.4.0

Kalender is een van onze meest populaire widgets in de YUI 2 familie, en het is het maken van zijn debuut op de YUI 3 architectuur in 3.4.0. Allen Rabinovich is het onderdeel eigenaar en auteur en zal op de oproep herintroduceren we deze oude favoriet, met een aantal nieuwe benaderingen van problemen van 2.x Agenda. Ik ben in het bijzonder Jazzed over de steun voor internationalisering, maar de nieuwe rendering regels zijn ook behoorlijk fascinerend.

Kom binnen, en breng je date-picker, event-kalender, import-van-iCal-and-make-pannenkoeken vragen en feature requests met u als we vlees uit de nu en de toekomst Y.Calendar . (Nee, het zal niet importeren iCal, maar als iemand wil een galerie module te maken om dat beest te temmen, is er zeker een YUIConf ticket zijn er voor jou ;))

We zijn terug naar onze gebruikelijke tijdstip van deze week, dus we zien je in Verbinding om 10 uur PDT.

Tijd & Details

We zullen online van 10u tot 11u PDT donderdag. De verbinding zijn identiek zoals gebruikelijk.

  1. Inbellen op 1-888-371-8922 (Skype werkt prima voor niet-Amerikaanse deelnemers *)
  2. Voer de deelnemer code 47188953 #
  3. Word lid van de delen van het scherm sessie (dit wordt u gevraagd de Adobe Connect-plugin te installeren als dit je eerste keer te gebruiken)

Let op: Omdat het een open conferentie lijn, vragen wij dat bellers hun lijnen uit te zetten, tenzij ze deelnemen aan actieve discussie.

* - Als Skype is geen optie, mail me of neem me (ls_n) in de # yui IRC kanaal op freenode voor een lokaal nummer.

Opname

Bedankt aan iedereen voor het bellen in! De online registratie van de sessie is nu beschikbaar.

De hoge kwaliteit, iPhone / iPad compatible, downloadbare opname is hier .

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

YUI: Open uur don 21 juli

19 juli 2011 om 02:16 uur door Luke Smith | In Ontwikkeling , Open Uur | 12 Commentaren

Een DataTable update en galerie showcase

De 3.4.0 release-cyclus komt ten einde en zal worden verpakt met allerlei geweldige functies, maar spreekt duidelijk, heeft DataTable niet gekregen zo veel ontwikkeling gericht zoals het zou moeten hebben. Er zijn een aantal bug fixes, maar, en een behoorlijke hoeveelheid planning voor veranderingen die gericht zijn in 3.5.0, en een goede start van betrokkenheid van de gemeenschap met de ontwikkeling ervan.

We weten dat DataTable is een ongelooflijk belangrijk widget voor veel klanten, dus we begrijpen de kosten van het uitstellen van gerichte ontwikkeling. Deze Open uur zal een update van wat werk wordt steeds gedaan voor 3.4.0, wat er gepland voor 3.5.0, en een inleiding tot het grote werk dat is begonnen te springen in de Galerij om functies toe te voegen en bugs voor DataTable (en vast haar familie van ondersteunende klassen).

We zullen online een uur eerder deze week in het voordeel van Eamon Brosnan (aka, Mosen van # Yui), die wordt aangeboden een aantal van de Gallery plekken kijken we naar boven. Anders zullen we moeten andere # yui bewoners en Galerij medewerkers tonen hun waren. Als je een DataTable oplossing of work in progress dat u wilt delen, laat het me weten zodat ik kan blokkeren van het schema om alles (ls_n in # yui of past twitter ).

Tijd & Details

We zullen online van 9u tot 10u PDT donderdag. De verbinding zijn identiek zoals gebruikelijk.

  1. Inbellen op 1-888-371-8922 (Skype werkt prima voor niet-Amerikaanse deelnemers *)
  2. Voer de deelnemer code 47188953 #
  3. Word lid van de delen van het scherm sessie (dit wordt u gevraagd de Adobe Connect-plugin te installeren als dit je eerste keer te gebruiken)

Let op: Omdat het een open conferentie lijn, vragen wij dat bellers hun lijnen uit te zetten, tenzij ze deelnemen aan actieve discussie.

* - Als Skype is geen optie, mail me of neem me (ls_n) in de # yui IRC kanaal op freenode voor een lokaal nummer.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

Next-Gen YSlow powered by YUI

18 juli 2011 om 21:17 door Marcel Duran | In Ontwikkeling , Uitvoering | 4 Opmerkingen

Een paar weken geleden, Yahoo! kondigde YSlow for Mobile op Velocity 2011 , waardoor de kracht van YSlow prestatie-analyse naar de mobiele wereld.

YSlow voor Mobile werkt als een bookmarklet , die het mogelijk maakt om te draaien op andere browsers dan Firefox (als een add-on) of Chrome (als extensie) .

De YSlow architectuur werd gedeeltelijk opnieuw ontworpen om te werken cross-platform en YUI was de belangrijkste factor in het maken sandboxing, cross-browser abstractie en eenvoudig YQL toegang mogelijk te maken.

Sandboxing

Om te worden ingebed op een pagina zonder zich te bemoeien met de prestatie-analyse en zonder knoeien met de pagina zelf, YSlow is een bookmarklet die JavaScript en CSS injecteert in een pagina door gebruik te maken van de kracht van YUI sandboxing:

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 (). schrijven ('
         <head>
         <Body onload = "
             YUI_config = {
                 win: window.parent,
                 doc: window.parent.document
             };
             var d = document;
             d.getElementsByTagName (\ 'hoofd \') [0]
                 . AppendChild (
                     d.createElement (\ 'script \')
                 ). Src = \ 'http://d.yimg.com/jc/yslow-bookmarklet.js \' "
         >
     ');
     o.close ()
 } (Document))

De code hierboven in:

  • maakt een lege iframe;
  • deze toegevoegd aan de pagina lichaam;
  • verbergt de iframe *;
  • krijgt het venster handler;
  • schrijft in de inhoud ervan het lichaam van de iframe;
  • dit lichaam is leeg, maar heeft een onload event
  • de onload event bepaalt hoe te injecteren YSlow JS:
    • stelt YUI_config , zo win en doc verwijst naar de pagina die wordt geanalyseerd window en document respectievelijk
    • dynamisch injecteert YSlow URL door een script element in iframe's head

* De iframe wordt weergegeven tegen de tijd dat alle YSlow presentatie activa worden geladen

Dit plaatst een iframe in de pagina wordt geanalyseerd. Dit iframe zal fungeren als een zandbak omgeving en YSlow zal verblijven op het. Aangezien het iframe wordt dynamisch gemaakt zonder de src attribuut, zal het de toegang tot zijn ouder (de pagina die wordt geanalyseerd) omdat er geen beleid voor dezelfde oorsprong overtreding gebeurt daar.

De YUI_config object handig is, omdat het stelt win en doc aan de moedermaatschappij van de iframe's (de pagina die wordt geanalyseerd), dus alle nieuwe YUI Zo zal worden gebonden aan het bovenliggende document standaard bedrading elke oproep tot Y.all en Y.one door Y.config.win of Y.config.doc van de YUI use terugbellen.

YSlow's presentatie is in handen van de iframe window en document referenties, waardoor de YSlow belangrijkste script om de opmaak te maken, alsmede de externe CSS binnen dit iframe te halen zonder in conflict met stijlen de bovenliggende pagina's. YSlow scant de bovenliggende pagina in om alle componenten (afbeeldingen, scripts, links, achtergrond-afbeeldingen, flash, etc.) die nodig zijn voor latere prestatie-analyse te krijgen. Dit wordt gedaan door de toegang tot Y.config.win en Y.config.doc , omdat zij verwijzen naar de bovenliggende pagina.

Cross-browser abstractie

Omdat het een bookmarklet, is YSlow voor Mobile geacht te werken op elke browser *. YUI abstraheert cross-browser problemen door het normaliseren van browser verschillen, wat resulteert in een schone, eenvoudig te lezen en te onderhouden codebase.

YSlow is niet volledig overgezet naar YUI 3 - alleen de controller laag (van de komende App component) voor nu - maar toch, alle DOM manipulatie en event handling worden gedaan door de node -en event modules. In toekomstige releases zijn we van plan om meer YSlow functies over te zetten naar YUI 3.

* Niet alle browsers worden momenteel ondersteund

YQL

YSlow analyseert pagina's door het controleren van de HTTP-headers voor de componenten vinden op de pagina. HTTP response headers zijn niet beschikbaar in de pagina, dus die onderdelen opnieuw moeten worden aangevraagd met het oog voor YSlow te krijgen van de response header informatie. Dit kan worden bereikt door het vragen van de lijst van de component-URL's door middel van XMLHttpRequest (AJAX) maar helaas als gevolg van beleid voor dezelfde oorsprong beperking , is dit niet mogelijk, tenzij alle onderdelen in hetzelfde domein als de pagina die is zeer onwaarschijnlijk.

Een gemeenschappelijke oplossing voor het beleid voor dezelfde oorsprong beperking wordt met behulp van JSONP, waar een externe server werkt als een proxy verzoek aan de lijst met onderdelen URL's en het ophalen van hun HTTP response headers namens YSlow. Door de populariteit YSlow's en de recente mobiele prestaties analyse-inspanningen, verwachten we vrij zwaar verkeer voor de YSlow voor mobiele bookmarklet. Om dit vervoer te ondersteunen, YQL was de schaalbare oplossing van YSlow door middel van een open data tabel met de naam data.headers , die de respons headers en inhoud haalt voor een bepaalde lijst met URL's, terwijl zich voordoen als de user-agent om ervoor te zorgen de verwachte inhoud opgehaald.

De YQL Query component doet al het werk van het beheer van YQL vragen, terwijl het beheer JSONP verzoeken onder de motorkap, waardoor de YSlow controller code veel eenvoudiger en makkelijk te onderhouden.

Toekomstige uitbreidingen: Nieuwe YSlow voor Mobile interface

Momenteel is de YSlow voor mobiele gebruikerservaring is hetzelfde als de desktop ervaring. Omgaan met een lange lijst van prestatie-analyse van gegevens is niet de beste ervaring op kleine smartphone-schermen. Sinds YUI ook abstraheert cross-apparaat gebaren , YSlow voor Mobile zal een gloednieuwe mobiele interface te krijgen in toekomstige versies.

Prestaties van de prestaties van gereedschap

YSlow voor mobiele inzet werd zorgvuldig gezien de prestaties van invloed op de laadtijd van de pagina die wordt geanalyseerd. De YUI 3 modules gebruikt worden op YSlow werden onderzocht om alleen de modules die nodig zijn om YSlow laden zo snel mogelijk op te nemen. De YUI zaad bestand en Loader werden niet opgenomen omdat alle noodzakelijke modules en submodules werden samengevoegd volgende optreden Ryan Grove's Zen tips, die het mogelijk maakten om samen te laden alles in een kleine enkel verzoek: YSlow-bookmarklet.js: 204kB, 66KB ( gzip) waarbij:

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

Meer informatie over YSlow

Keep up-to-date met de laatste YSlow aankondigingen door:

Marcel Duran Over de auteur: Marcel Duran is de Front End Lead voor Yahoo! 's Uitzonderlijk Performance Team. Hij is in web optimalisatie van prestaties op high traffic sites in Yahoo! Front Page en Search teams waar hij toegepast en onderzocht webprestaties best practices maken van pagina's nog sneller. Hij is nu gewijd aan YSlow en andere prestatie-instrumenten ontwikkelen, onderzoeken en evangelisatie. Zijn doel is om het internet nog sneller te maken dan het kan zijn en gelooft dat er niet zoiets als "slechts een paar milliseconden kan geen kwaad".

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

Graded Browser Support Update

12 juli 2011 om 20:55 door Jenny Donnelly en Matt Sweeney | In Ontwikkeling , Graded Browser Ondersteuning | 24 Commentaren

GBS Wijzigingen

Specifieke veranderingen voor deze update zijn onder andere:

Browser Test Baseline

Internet Explorer 6,0 7,0 8,0 9,0
Firefox 3. † 4. † 5. †
Chrome † Laatste stabiele
Safari 5. † iOS 3. † iOS 4. †
Webkit Android 2. †

Opmerkingen:

  • De dolk symbool (zoals in "Firefox 4. †") geeft aan dat de meest huidige niet-beta-versie bij dat bijkantoor niveau voldoende steun is.
  • Wordt geen leidraad gegeven op iOS-of Android-OS-apparaat gebruik. De aanbeveling is dat je de apparaten die het meest representatief zijn voor uw gebruikersnaam basis voor elk OS te kiezen.

Het verwijderen van Cijfers vanuit de Browser Test Baseline

Deze editie van de GBS-update staat voor een vertrek van onze vorige updates in dat we afgestapt van mapping browsers direct naar ervaring graden (bijvoorbeeld "A-kwaliteit" en "C-grade"). In plaats van voorschrijven wat gebruikerservaring geschikt is voor welke browsers, we zullen concentreren op de definitie van een efficiënte basislijn teststrategie dat testdekking maximaliseert en minimaliseert het testen oppervlak. Bijvoorbeeld, IE6 is nog steeds significante wereldwijde marktaandeel reden is tot voortzetting testen, maar de huidige GBS maakt het mogelijk om IE6 gebruikerservaring anders te zijn dan de IE9 ervaring.

Het verwijderen van besturingssystemen vanuit de Browser Test Baseline

Met het oog op het testen te stroomlijnen en het minimaliseren van de benodigde middelen, we niet langer aangeven welk besturingssysteem moet worden getest op. De enige uitzondering is wanneer de browser wordt strak gekoppeld aan de OS-versie, in welk geval verwijzen we naar de versie van het besturingssysteem in plaats van de browser versie (bv. "Safari iOS 4"). Dit laat ons toe testdekking richten op browser-versies, en redudant testen op verschillende platforms te minimaliseren. Problemen met dezelfde browser over versies zijn te verwaarlozen, en in het algemeen gerelateerd aan een hoger niveau OS verschillen, zoals de belangrijkste handling en beschikbare lettertypen. Code die bekend staat om aan te raken op cross-platform kwesties moeten worden getest op zoveel mogelijk platforms mogelijk, maar deze test over het algemeen kunnen worden geïsoleerd om de specifieke problemen in plaats van het uitvoeren van een volledige regressie test van alle functies. Wij raden het uitlijnen besturingssysteem testen prioriteit met uw gebruikersnaam basis.

Waarom is IE6 nog op de lijst?

IE6 heeft nog steeds een significant genoeg wereldwijde marktaandeel aan een geverifieerd aanvaardbaar gebruikerservaring te rechtvaardigen. Een veel voorkomende misvatting met de Progressive Enhancement strategie is dat wanneer een browser "C-grade" dat het wordt "ondersteund", gaat terwijl het in feite werkelijk betekent dat het de HTML-enige ervaring worden geleverd. Nu we niet langer voor te schrijven welke browsers welke ervaring dan is dit meer voor projecten om te beslissen op basis van hun gebruikers en middelen. De GBS richt zich op te geven welke browsers moet een geverifieerde bruikbare ervaring op basis van factoren zoals marktaandeel en invloed. Het definiëren van wat is 'bruikbaar' en specifiying aanvaardbare niveaus van degradatie blijven voor teams om te beslissen. We hebben nog steeds het bevorderen van een eenvoudige Progressive Enhancement model, en ontmoedigen projecten van het creëren van nieuwe lagen, zonder administratieve verwerking van de extra kosten in ontwikkeling, testen en het onderhoud middelen.

GBS Forecast

We verwachten de volgende wijzigingen in de volgende update te maken:

  • Stop met dekking voor Safari op iOS 3.
  • Voeg dekking voor Webkit op Android 3.
  • Voeg dekking voor Firefox 6.
  • Voeg dekking voor Safari iOS 5.

De GBS Archief

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

De "MakeNode" Widget Extension

8 juli 2011 om 14:11 door Satyam | In ontwikkeling | 6 Commentaren

Noot van de redactie: Aangezien dit artikel werd oorspronkelijk gepubliceerd, de MakeNode module is gepubliceerd op de YUI Gallery en kreeg een aantal verbeteringen. Raadpleeg het bijgewerkte artikel, update: De "MakeNode" Widget Extension .

In mijn vorige artikel, een recept voor een YUI 3 Toepassing , liet ik een manier om te gebruiken Y.substitute als een zeer basic template processor. Het idee nam het leven van daar, met suggesties van de mensen in de # Yui IRC kanaal, en ik maakte er een Widget extensie die beschikbaar is op mijn site, genaamd MakeNode . MakeNode is geen algemene template processor en is niet bedoeld als een. Aan de andere kant, is het nauw geïntegreerd met de YUI Widget stichting klasse, met inbegrip className en evenementen helpers en internationalisering. In dit artikel zal ik de Spinner voorbeeld en aanpassen aan de richtlijnen van mijn vorige artikel te volgen en te MakeNode gebruiken. De gewijzigde Spinner component ( JS , CSS , sprites ), en een voorbeeld zijn beschikbaar op mijn site. Links naar extra middelen kan gevonden worden op het einde van dit artikel.

Uitbreiding van uw component

Zodra MakeNode is geladen, moet u de module in uw onder andere YUI().use() verklaring onder de naam 'makenode' . Dan, om de widget te breiden, kunt u een lijst in de derde argument om Y.Base.create() , zoals deze: 

  Y.Spinner = Y.Base.create (
      'Spinner',
      Y.Widget,
      [Y.MakeNode]
      {
         / / Instance leden ...
      }
      {
          / / Statische leden
      }
 );

U MakeNode toevoegen langs een aantal geschikte extensies voor Widget zoals WidgetParent, WidgetChild, WidgetStdMode enz. MakeNode voegt twee beschermde methoden _makeNode en _locateNodes, en leest van verschillende statische eigenschappen, indien aanwezig.

Alle leden van deze uitbreiding zijn of beschermde of prive, omdat ze zijn bedoeld om gebruikt te worden door de component ontwikkelaar en niet door de uitvoerder gebruik van deze componenten, die niet moet worden lastig gevallen met hen.

Het definiëren van de Template

Het eerste wat je normaal gesproken doen is om de sjabloon te definiëren voor uw component. Voor de Spinner, zal onze template zijn: 

  _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'),

De standaard template zal meestal de naam _TEMPLATE en verklaarde langs de andere statische eigenschappen van de klasse, zoals ATTRS . MakeNode zal gebruik maken van dit sjabloon als geen ander wordt uitdrukkelijk voorzien. De mal is normaal HTML en een reeks aanduidingen tussen accolades, elk gemaakt van een teken (verwerking code) en gevolgd door een of meer argumenten. De tijdelijke aanduidingen en wat ze produceren zijn:

  • {@ attributeName} configuratie attribuutwaarde

  • {p propertyName} bijvoorbeeld waarde van de eigenschap

  • {m methodName arg1 arg2 ….} return waarde van de gegeven methode. De verwerking code wordt gevolgd door de werkwijze naam en een aantal argumenten gescheiden door een spatie. Strings moeten tussen dubbele aanhalingstekens. Cijfers, Booleans en null worden omgezet van string naar de juiste data types

  • {c classNameKey} CSS className gegenereerd uit de _CLASS_NAMES statische eigenschap

  • {s key} koord uit de strings attribuut, met behulp van key als de sub-attribuut.

  • {? other placeholder } Geeft de string checked wanneer het resultaat van de verwerking van de rest van de tijdelijke aanduiding is waar.

  • {} een andere waarde zal worden behandeld, net als Y.substitute doet.

Bijvoorbeeld: {@ value} zal leiden tot een this.get('value') , terwijl {p value} vertaalt naar this['value'] .

De {m} tijdelijke aanduiding is een beetje complexer. Het eerste argument na m verwerkingscode de naam van de werkwijze en de rest van de argumenten elkaar gescheiden door een spatie, dat wordt doorgegeven aan de gegeven methode. Deze argumenten kunnen getallen, null , true , false of strings tussen dubbele aanhalingstekens. MakeNode zal ontleden ze en ze converteren naar hun juiste types, dus {m myMethod 123.45 true “this is a string”} zal resulteren in te roepen this.myMethod(123.45, true, “this is a string”) , zodat de eerste twee argumenten worden omgezet in de juiste gegevens types en het koord kunnen spaties. Om een dubbel aanhalingsteken, gebruikt u \\" , de dubbele backslash is vereist omdat JavaScript zal een enkele interpreteren en ontdoet voordat het MakeNode aan. Alleen dubbele aanhalingstekens zijn toegestaan, MakeNode maakt geen gebruik van eval() , zodat de parser is beperkt maar veilig. Alles behalve cijfers, null , Booleans en dubbele aanhalingstekens worden genegeerd.

De {?} tijdelijke aanduiding is het handig om te gebruiken met selectievakjes en keuzerondjes. Het zal produceren de string “checked” , afhankelijk van de waarheidswaarde van de verwerking instructie code die volgt. Zo <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/> zal een duidelijke optie als de getLength methode retourneert iets anders dan nul. {?} zal een van de andere tijdelijke aanduidingen te accepteren, al is het alleen zin heeft met de eerste drie.

Voor de {c} tijdelijke aanduiding, moeten we beschikken over een _CLASS_NAMES eigendom gedefinieerd.

Verder aanduidingen worden toegevoegd MakeNode door ze in de _templateHandlers hash.

De _CLASS_NAMES woning

Samen met de ATTRS en _TEMPLATE statische attributen kunnen definiëren we een _CLASS_NAMES woning die wijst naar een array van strings. Elk van deze reeksen wordt gebruikt om een ​​className genereren. Zo _CLASS_NAMES: ['input'] zal de className produceren “yui3-spinner-input” . Die classNames worden opgeslagen in een instantie eigendom this._classNames . De {c input} tijdelijke aanduiding in het sjabloon hierboven zal worden vervangen door “yui3-spinner-input” .

U kunt de _CLASS_NAMES eigenschap om het even welk aantal classNames te genereren, of je ze kunt gebruiken in de sjabloon of niet. U kunt nog steeds te bereiken die extra classNames van binnenuit this._classNames . De className wordt met de yui3 prefix gevolgd door de waarde van de NAME statische eigenschap werd kleine en de snaar in _CLASS_NAMES (deze laatste niet ingeschakeld kleine) van elkaar gescheiden door streepjes. De _classNames hash zal ook de classNames voor de boundingBox en de contentBox , de eerste onder het "." toets en de tweede onder de “content” te drukken. Widget toekent aan de boundingBox de classNames afgeleid van de waarden van de NAME eigendom van elk van de klassen in de erfenis keten, te beginnen met yui3-widget . MakeNode winkels in this._classNames alleen de bovenste className voor de boundingBox .

Als een component verschillende niveaus uit de buurt van Widget, zoals SuperSpecialSpinner erven van SuperSpinner die erft van Spinner , die erft van Widget, en als enige of alle van hen hebben _CLASS_NAMES eigenschappen die zijn gedefinieerd, MakeNode zal classNames produceren voor hen allemaal en bewaar ze in this._classNames . U hoeft niet op te nemen op elk niveau de namen al opgegeven in de laatste levels. In feite is het beter dat je niet omdat de classNames geproduceerd op elk niveau zal de waarde van het gebruik NAME eigendom van dat niveau. Zo werd in SuperSpecialSpinner , {c input} zal nog resulteren in “yui3-spinner-input” en niet “yui3-superspecialspinner-input” en zo zal uw CSS-bestand nog geldig is.

Het {s} tijdelijke aanduiding

Widget heeft een strings gedefinieerde configuratie attribuut, maar het is niet geïnitialiseerd met een waarde. Dit attribuut is bedoeld om strings die zichtbaar zijn voor (of, via schermlezers, lezen) van de gebruiker vast te houden. Het is belangrijk dat je nooit zichtbare strings rechtstreeks in de sjabloon op te nemen. Dit is niet een vereiste van MakeNode - het is nooit een goed idee. Alle strings die moeten worden bekeken door of lees de gebruiker moet altijd worden geplaatst in de strings attribuut. De strings attribuut bevat een hash waarbij elke individuele tekst ligt bij de belangrijkste. De Spinner-component heeft de volgende snaren, die u kunt zien in het sjabloon hierboven. 

  strings: {
     waarde: {
         ingang: "Druk op de pijl omhoog / omlaag toetsen voor kleine stappen, page up / down voor grote stappen."
         op: "Increment",
         naar beneden: "Afname"
     }
 }

Het beste deel van dit te doen is dat uw component kan worden gelokaliseerd in andere talen heel gemakkelijk door ontwikkelaars met behulp van uw component. Bij het maken van een exemplaar van Spinner, je zou kunnen doen: 

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

Het instellen van de configuratie attribuut strings op deze manier vervangt de standaard strings waarden met die van de taal resource file met behulp van de taal eerder gedefinieerd. Het {s} tijdelijke aanduiding geeft toegang tot de strings zijn opgeslagen in de strings attribuut, ofwel de standaard instellingen of de vertaalde die, indien ingesteld. Het {s xxxx} tijdelijke aanduiding is in feite niets meer dan een snelkoppeling naar de {@ strings.xxxx} tijdelijke aanduiding. Echter, de eerste alleen toegang snaren op het hoogste niveau terwijl bijvoorbeeld, {@ strings.xxxx.yyyy.zzzz} laat je toe om een string te openen dieper naar beneden.

Met behulp van _makeNode in renderUI

We maken gebruik van de sjabloon om de opmaak voor onze component te creëren. Om dit te doen, kunnen we MakeNode's _makeNode methode, zoals deze: 

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

Dit vult de contentBox van onze widget met de opmaak van de verwerking van de sjabloon. De _makeNode methode geeft een voorbeeld van Y.Node die kunnen worden toegevoegd of waar dan ook of gewoon aangehouden voor later gebruik geplaatst. Het maakt niet terug een string, produceert het een Node bijvoorbeeld.

De _makeNode methode houdt twee opties: een verwijzing naar een sjabloon en een object in te vullen tijdelijke aanduidingen, zoals Y.substitute doet. In ons eenvoudige Spinner Zo is er een sjabloon voor het hele widget maar ook andere widgets zou kunnen vereisen stukjes en beetjes uit verschillende templates gemaakt. In dat geval zou je meestal noemen _makeNode zonder argumenten voor het grootste deel en noem het opnieuw met verschillende sjablonen te vullen in de extra onderdelen. De voorbeeld bevat deze renderUI methode: 

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

De eerste oproep tot _makeNode geeft een Node bijvoorbeeld opgeslagen in de variabele fieldset . Het monster component is ook uitgebreid met Y.ArrayList zodat RADIO_TEMPLATE wordt gevuld met waarden uit de items in de array lijst en de resulterende knooppunten toegevoegd aan de fieldset voordat het uiteindelijk toegevoegd aan de contentBox . De speciale tijdelijke aanduidingen, zoals {@} of {p} nog steeds verwijzen naar attributen of eigenschappen in het hoofddoel. De geneste items worden verwerkt net zo Y.substitute zou doen.

De _locateNodes methode

MakeNode voorziet verder in een _locateNodes methode die zal proberen om alle elementen met de classNames verklaarde in vinden _CLASS_NAMES . Voor de locatie specifieke elementen kunt u een aantal className toetsen passeren, anders _locateNodes probeert ze allemaal. Voor elk element gevonden van elke className, _locateNodes zal een eigen instantie accommodatie via de underscore prefix gevolgd door de toets naam en het “Node” achtervoegsel. Dus, in ons voorbeeld Spinner, _locateNodes genereert de eigenschappen _inputNode , _upNode en _downNode . Als er meerdere elementen hebben dezelfde className, _locateNodes zal een verwijzing terug naar de eerste van hen. Als een element niet wordt gevonden, zal er geen variabele worden gecreëerd.

In de Spinner-component die we gebruiken _locateNodes na het maken van de opmaak: 

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

De _EVENTS statische eigenschap

Een extra goed kan worden omschreven langs de lijnen van _TEMPLATE en _CLASS_NAMES en dat is _EVENTS . _EVENTS zal een hash gemaakt van eersteklas naam toetsen, die elk een hash van soorten gebeurtenissen en methoden om te gaan bevatten. Het is beter toegelicht met een voorbeeld: 

  _EVENTS {
     '.' {
         sleutel: {
             fn '_onDirectionKey,
             args: ((Y.UA.opera) "naar beneden:":? "pers:") + "38, 40, 33, 34"
         }
         mousedown: '_onMouseDown'
     }
     '..': {
         mouseUp '_onDocMouseUp'
     }
     ingang: {
         verandering: '_onInputChange'
     }
 }

_EVENTS is een object (een hash) met een willekeurig aantal eigenschappen. De namen van de eigenschappen, dat wil zeggen de sleutels van de hash, identificeren van de elementen waarvan de evenementen die we zullen luisteren. Het zijn dezelfde kenmerken die in _CLASS_NAMES . Er zijn twee extra speciale toetsen "." en ".." . Hoewel de className toetsen naar elementen genest in de contentBox , de "." sleutel verwijst naar de boundingBox zelf terwijl ".." verwijst naar het document met dit widget. Je moet dit zien als het doen van een chdir commando wanneer zich aan de boundingBox niveau. De _EVENTS woning is verwerkt nadat de renderUI , bindUI en syncUI methoden zijn genoemd, zodat de widget zal naar verwachting al worden ingevoegd in het document lichaam, anders wordt de ".." zal mislukken.

Elk van de items in _EVENTS is een verder doel dat het type evenement gebruikt als de belangrijkste en de naam van een instantie methode om te gaan. _EVENTS , die een statische variabele, heeft geen toegang tot this dus het kan niet de werkelijke functie referenties, alleen de naam van de gebeurtenislistenermethode. Sommige soorten gebeurtenissen hebben extra argumenten, zoals de key gebeurtenis. In dat geval, in plaats van de naam van de gebeurtenishandler u kan een object met eigenschappen fn en args de functie naam en de extra argumenten houden indien nodig.

MakeNode zal gebruik maken van Node.delegate om te luisteren naar de gebeurtenissen van de geneste elementen, terwijl het zal gebruik maken van Y.on om te luisteren naar gebeurtenissen uit de boundingBox en het document lichaam. (Note: listening to the key event on any nested element works only with version 3.4.0pr1 and above, since delegation of the key event was not available before. All the other features work with previous versions as well.)

The _EVENTS declarations are cumulative when components inherit from one another. Each class in the inheritance chain will have its own _EVENTS declaration processed separately.

The _ATTRS_2_UI static property

Events go both ways, from the UI to the component and from the component to the UI. The first are handled by the _EVENTS property. Then there are the events fired by attribute value changes that need to be reflected in the user interface. 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) {
        return;
     }
    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.

Conclusie

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:

The API docs can be found here .

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

YUI en Loader veranderingen voor 3.4.0

July 1, 2011 at 6:34 am by Dav Glass | In Development , Performance | 10 Comments

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. Bijvoorbeeld: 

    "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.

De Toekomst

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.

Zoek gesprekken: Bloglines | technorati

Delen en uit te breiden: Bookmark met del.icio.us | Digg it! | reddit!

Hosted by Yahoo!

Copyright © 2006-2012 Yahoo! Inc Alle rechten voorbehouden. Privacy Policy - Gebruiksvoorwaarden

Powered by WordPress op Yahoo! Web Hosting .