Yahoo! User Interface Blog (YUIBlog)

YUIConf 2011 Early Bird registratie is nu open

30 september 2011 om 21:31 door Jenny Donnelly | In Ontwikkeling , YUI Events | 4 Opmerkingen

Early-bird registratie voor YUIConf 2011 is nu open op Eventbrite! Dit jaar is het evenement zal worden gehouden 02-4 november op Yahoo! 's Great America campus. We zijn verheugd om u een volledige dag van hands-on workshops (wo), gevolgd door twee volle dagen van de tech praat over YUI (do / vr). De inschrijving voor de conferentie kost 75 dollar dit jaar, met een vroege-vogel-tarief van $ 50. De inschrijving voor de workshops staat los van de conferentie en details worden binnenkort.

Wij zijn bezig met voering grote onderwerpen, waaronder:

• YUI component diepe duiken, met inbegrip van Dial en Agenda
• YUI in mobiele omgevingen
• Testen met YUI
• Real-world migratie verhalen
• en nog veel meer!

Zoals altijd zal conferentie sessies video-opnames en beschikbaar zijn op YUI Theater en ons YouTube-kanaal voor iedereen om van te genieten.

Hoop je daar te zien!

(Belangrijk! Interne Yahoos kunt u zich inschrijven voor een Yahoo!-Employee ticket en bieden je werk e-mailadres.)

Zoek gesprekken: Bloglines | technorati

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

YUI 3.4.1 is nu live

27 september 2011 om 14:37 door Allen Rabinovich | In ontwikkeling | 8 Opmerkingen

De YUI 3.4.1 korte cyclus versie is nu beschikbaar op CDN en voor het downloaden , meer dan een week te vroeg! Hier zijn een paar hoogtepunten van deze release:

• Meer dan 150 bug fixes voor de Controller , Panel , DataTable , kalender , en een aantal andere modules.
• Bug fixes aan Y.substitute () door YUI contribuant Satyam .
• Japanse taal ondersteuning voor Calendar en Console , met dank aan YUI bijdrage Ryuichi Okumura .
• Diverse aanpassingen aan de documentatie en voorbeelden.

U kunt kunt ook de samenvatting van alle veranderingen opgemerkt in het onderdeel geschiedenis-bestanden voor YUI 3.4.1 , alsmede de volledige lijst van tickets aan bod tijdens de YUI 3.4.1 ontwikkeling . Zoals altijd, zouden wij het op prijs dat u suggesties die u heeft of gebreken u misschien te ontdekken in onze ticketshop databasebestand. Feedback voor YUI 3.4.1 kan worden ingevoerd in de YUI 3 ticket-database .

We willen ook graag aan te kondigen dat in de volgende versie van YUI, DataType.Date, DataType.Number en DataType.XML zal worden afgeschaft ten gunste van Y.Date, Y.Number en Y.XML respectievelijk. Backwards compatibiliteit zal worden bewaard voor een release, om iedereen de kans om over te schakelen.

Oh, en nog een ding: we zijn goed op weg in het migreren van de YUI Theater inhoud op YouTube . Om te beginnen, kijk op Douglas Crockford van de lezingenreeks "Crockford van JavaScript" - compleet met ondertitels!

Zoek gesprekken: Bloglines | technorati

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

Stem voor YUI in de Open Source Awards Finals

26 september 2011 om 21:21 door Jenny Donnelly | In Diversen | 1 Reactie

Dank aan iedereen die YUI genomineerd voor de Packt Publishing Open Source Awards. Stem nu voor YUI als uw favoriete JavaScript-bibliotheek!

Zoek gesprekken: Bloglines | technorati

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

YUI 3.4.1 PR1 nu beschikbaar op CDN

22 september 2011 om 13:35 door Jenny Donnelly | In Ontwikkeling | 1 Reactie

YUI 3.4.1 PR1 is nu beschikbaar voor de gemeenschap testen en feedback. Het is beschikbaar op de Yahoo! CDN op http://yui.yahooapis.com/3.4.1pr1/build/yui/yui-min.js , en je ziet de veranderingen in te gaan op 3.4.1 uit de lijst van de gecontroleerde tickets in voor de release .

De 3.4.1 release zal een kleinere bug-fix release met een verkorte ontwikkelingscyclus, gepland voor go-live van 05 oktober zijn. Gelieve bestand bugs en ​​regressies in het ticket database op YUILibrary.com door de ochtend van maandag 26 september, zodat we kunnen zorgen dat alle belangrijke onderwerpen komen aan bod voor de algemene release. Als er geen dringende problemen worden gemeld, zullen we hem loslaten 3.4.1 reeds in september 27e.

Zoek gesprekken: Bloglines | technorati

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

YUI: Open uur don 15 september

12 september 2011 om 21:58 door Luke Smith | In Ontwikkeling , Open Uur | 2 Commentaren

Satyam MakeNode uitbreiding

Als je niet weet Satyam , moet je nieuw voor YUI. Hij is een pijler van de YUI gemeenschap sinds de vroege dagen van YUI 2. Zijn artikelen op YUIBlog zijn enkele van de meest gelezen en verwees naar bronnen voor stijl inhoud "hoe werkelijk de bibliotheek te gebruiken". Als je ziet dat Satyam het geschreven heb, het is de moeite waard de lees-, en waarschijnlijk, een re-lezen en een bladwijzer.

In juli, postte hij een groot artikel over een MakeNode Widget extensie die is gericht op een deel van de gemeenschappelijke patronen die bij de bouw van Widgets te vereenvoudigen en het gemakkelijker om gemeenschappelijke misstappen te vermijden. De module is inmiddels toegevoegd aan de galerij en net eerder vandaag, postte hij een update van zijn oorspronkelijke artikel.

Dat is wat we gaan het over. De kenmerken, de geschiedenis, en de redeneringen. Als u al gebruik van het onderdeel infrastructuur, en in het bijzonder, Y.Widget , je hebt waarschijnlijk ondervonden ten minste een deel van de hindernissen Satyam uiteengezet aan te pakken met MakeNode . Dit wordt een 'best practices fest te zijn, dus neem uw kladblok, en uw eigen ervaringen te delen.

Tijd & Details

We zullen online op donderdag van 10u tot 11u PDT.

Deelnemen aan de vergadering

Opname

De opname is beschikbaar in de YUILibrary YouTube kanaal .

Zoek gesprekken: Bloglines | technorati

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

Voeg een Talk voor YUIConf 2011

12 september 2011 om 15:48 door Jenny Donnelly | In Ontwikkeling , YUI Events | No Comments

Pronk met code die je hebt gewerkt of het verdelen van iets wat je hebt geleerd tijdens het werken met YUI! Dien uw voorstel om yui-events (at) yahoo-inc.com door vrijdag de 23 september 2011. Zorg ervoor dat u onder andere:

• Titel
• Beschrijving
• Doelgroep
• Uw naam
• Een korte bio

YUIConf 2011 zal worden gehouden 03 november en 4 op Yahoo! 's Santa Clara, CA campus. Uw presentatie moet duren ongeveer 45 minuten. We zullen tot 15 minuten na uw presentatie voor Q & A. Bericht vragen in de comments, of direct e-mail naar yui-events (at) hotmail-inc.com.

Zoek gesprekken: Bloglines | technorati

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

Update: De "MakeNode" Widget Extension

12 september 2011 om 15:18 door Satyam | In Ontwikkeling , YUI 3 Galerij | 8 Opmerkingen

Nota van de redacteur: Dit artikel is oorspronkelijk gepubliceerd eerder dit jaar . Sindsdien is het is MakeNode module is gepubliceerd op de YUI Gallery en kreeg een aantal verbeteringen. De huidige artikel reflecteerd de laatste wijzigingen aan MakeNode.

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 de YUI Gallery, 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. MakeNode is beschikbaar als een gallery component en de gewijzigde Spinner component en de voorbeeld die zullen worden gebruikt in dit artikel .

Uitbreiding van uw component

Om MakeNode te laden moet je de module in uw onder andere YUI().use() verklaring onder de naam 'gallery-makenode' of, als het definiëren van een module via YUI.add() , vermeld het als het requires array. 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 kunt MakeNode toe te voegen langs een aantal geschikte extensies voor Widget, zoals WidgetParent, WidgetChild, WidgetStdMode, etc. MakeNode voegt twee beschermde methoden die worden gebruikt door de ontwikkelaar, _makeNode en _locateNodes, en het zal lezen uit verschillende statische eigenschappen, indien gevonden .

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. Vergeet niet om de "Show Protected" optie te controleren wanneer het bekijken van de API docs .

Het definiëren van de sjabloon

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.

• {c classNameKey} CSS className gegenereerd uit de _CLASS_NAMES statische eigenschap (zie De _CLASS_NAMES eigendom hieronder)

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

• {? condition valueIfTrue valueIfFalse } net als de ?: exploitant van JavaScript, evalueert tot valueIfTrue als de conditie truish, valueIfFalse anders.

• {1 condition valueIfOne valueIfMore } gebruikt voor het enkelvoud / meervoud, gebaseerd op de waarde van de toestand te produceren.

• {} 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'] .

Bij tijdelijke aanduidingen argumenten hebben, zoals {m} , {?} en {1} , moet strings tussen dubbele aanhalingstekens. Cijfers, booleans en null (alle niet-beursgenoteerde) zal worden ontleed naar de juiste data types. Tijdelijke aanduidingen kunnen worden genest. De {?} en {1} aanduidingen bevat meestal een geneste aanduiding voor de aandoening en mogelijk voor de waarden, bijvoorbeeld:

  {Aantal p} {1} {p aantal "eenheid" "units"} 

Als de eigenschap qty is 1, zal het evalueren "1 unit" , 2 of meer is terug "2 units" enzovoorts. Een uitgebreidere versie behandeling nul zijn:

  {?  {Aantal p} "{p aantal} {1} {p aantal" eenheid "" units "}" "none"} 

Merk op dat het resultaat van de verwerking van de innerlijke tijdelijke aanduidingen, als een string, moeten worden opgesloten in zijn eigen set van citaten.

Om een dubbel aanhalingsteken binnen de string, gebruikt u \\" , de dubbele backslash is vereist omdat JavaScript zal een enkele interpreteren en ontdoet voordat het MakeNode op Alleen dubbele aanhalingstekens zijn toegestaan;. MakeNode maakt geen gebruik van eval() , zodat de parser is beperkt, maar veilig is. Alles behalve cijfers, null , booleans en dubbele aanhalingstekens worden genegeerd.

De {?} tijdelijke aanduiding is ook handig te gebruiken met selectievakjes en keuzerondjes. Het kan gebruikt wordt om de reeks "checked" afhankelijk waarheidswaarde van de verwerkingsopdracht code volgt. Zo <input type="checkbox" {? {m getLength} "checked" ""}/> <input type="checkbox" {? {m getLength} "checked" ""}/> zal een duidelijke checkbox te produceren als de getLength methode retourneert iets anders dan nul.

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 eigenschappen, kunnen definiëren we een _CLASS_NAMES statische eigenschap 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" . Ik noem de snaren in _CLASS_NAMES , zoals 'input' , de 'className toetsen ", omdat ze kunnen worden gebruikt als sleutel om te verwijzen naar de werkelijke className of de elementen die deze classNames, zoals we later zullen zien.

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 de "boundingBox" 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 de WidgetStdMod module is geladen, zal MakeNode genereren ook inzendingen voor de HEADER , BODY en FOOTER secties met dezelfde sleutels, die ook de constanten in de zin van dezelfde module.

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 bijna als het gebruik van {@ strings.xxxx} , behalve dat de gelokaliseerde vervangende snaren kan tijdelijke aanduidingen die verder zal worden verwerkt. Dit is belangrijk voor vertalingen sinds syntactische volgorde verschilt van taal tot taal en dit laat herformulering van de tekst, met inbegrip van tijdelijke aanduidingen voor elke taal aan te passen. Strings kunnen ook worden geopend via {@ strings.xxxx.yyyy.zzzz} , die toegang zal toestaan ​​om strings dieper genest en voorkomt verdere vervangingen. Accolades kan worden opgenomen in een tekst met behulp van {LBRACE} en {RBRACE} als tijdelijke aanduidingen.

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. (Als je moet een string en geen Node, kunt u gebruik maken van de _substitute methode, die vereist dat je langs in een sjabloon.)

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 {
     ingang: 'verandering', / / ​​gesprekken this._afterInputChange
     BoundingBox: [
         {
             type: 'key',
             fn: '_onDirectionKey', / / ​​gesprekken this._onDirectionKey
             args: ((Y.UA.opera) "naar beneden:":? "pers:") + "38, 40, 33, 34"
         }
         'Muisklik' / / gesprekken this._afterBoundingBoxMousedown
     ]
     document: 'mouseUp', / / ​​gesprekken this._afterDocumentMouseup,
     Y: "broadcastingObject: someEvent '/ / noemt dit [" _afterYBroadcastingObject: someEvent "]
 } 

_EVENTS is een object (een hash) met een aantal inzendingen. De namen van de eigenschappen, dat wil zeggen de sleutels van de hash, identificeren van de knooppunten die evenementen die we zullen luisteren. Het zijn dezelfde className sleutels in de zin van _CLASS_NAMES . Er zijn verschillende extra speciale toetsen:

• "boundingBox" zullen verwijzen naar het selectiekader zelf.

• "document" verwijst naar het document met deze widget.

• "THIS" verwijst naar de widget zelf

• "Y" verwijst naar de Y instantie.

Als de Widget is uitgebreid met WidgetStdMod als goed, de toetsen HEADER , BODY en FOOTER zal verwijzen naar die delen, omdat ze beschikbaar zijn in de _classNames hash. JavaScript is niet nodig de sleutels te worden geciteerd als ze geldig zijn identifiers zo geen van de bovenstaande moeten worden aangehaald.

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 "document" identificatie zal falen.

Voor elk van deze elementen is er een gebeurtenis-id of een array van gebeurtenis-id. Een evenement kan worden geïdentificeerd door de aard van de gebeurtenis om naar te luisteren of een object met verdere details. Standaard zal MakeNode te gebruiken als een luisteraar een methode met de naam met behulp van de "_after" prefix, gevolgd door het element identificatie met zijn eerste teken geactiveerd, gevolgd door het type gebeurtenis met zijn eerste teken geactiveerd. De code blok hierboven toont de methoden genoemd voor elke gebeurtenis.

Een gebeurtenis identificatie kan ook een object met eigenschappen die type , fn en args . De type is verplicht en geeft het type evenement wordt geluisterd. De fn eigenschap geeft de naam van de methode die horen bij zodat geen automatische naamgeving. Aangezien _EVENTS een statisch eigenschap heeft geen toegang tot this zodat het een echte referentie niet op een werkwijze, maar de naam. De args argument kan worden gebruikt om verder gaat worden met de beller als de key gebeurtenis die een toetsen specificatie.

MakeNode zal gebruik maken van Node.delegate om te luisteren naar gebeurtenissen op elementen binnen de boundingBox , terwijl het zal gebruik maken van Node.after om te luisteren naar gebeurtenissen uit de boundingBox en het document lichaam. Het zal this.after aan om gebeurtenissen te luisteren onder het THIS -toets ingedrukt en Y.after voor luisteraars die onder de Y toets. Alle gebeurtenissen worden geluisterd naar het gebruik van na gebeurtenislisteners, omdat ze bedoeld zijn om de widget te reageren op gebeurtenissen, niet om het gedrag van het object dat vuurt ze zo in geen geval deze gebeurtenissen kunnen worden voorkomen of gestopt te filteren. (Let op: luisteren naar de key gebeurtenis op een geneste element werkt alleen met versie 3.4.0pr1 en hoger, omdat delegatie van de key gebeurtenis was niet beschikbaar voor alle andere functies werken met eerdere versies.).

De _EVENTS verklaringen zijn cumulatief wanneer componenten erven van elkaar. Elke klas in de erfenis keten heeft zijn eigen _EVENTS verklaring afzonderlijk verwerkt.

De _ATTRS_2_UI statische eigenschap

Evenementen in beide richtingen, van de gebruikersinterface om de component en van de component aan de gebruikersinterface. De eerste worden afgehandeld door de _EVENTS eigendom. Dan zijn er de gebeurtenissen afgevuurd door attribuutwaarde veranderingen die moeten worden weerspiegeld in de gebruikersinterface. Zoals ik in het vorige artikel, wanneer er geen secundaire gevolgen van het wijzigen van een configuratie attribuut, moeten zij worden behandeld door verandering gebeurtenislisteners, niet door de optionele setter methode van het attribuut, dat alleen zou gaan met het normaliseren van de waarde wordt ingesteld. De UI moet een weerspiegeling zijn van de toestand van de configuratie van attributen, eerst in syncUI , wanneer zij worden geïnitialiseerd en dan op elke attribuut gebeurtenis change. Voor deze laatste, moeten we een gebeurtenislistener hechten, die normaal gesproken zouden we doen in bindUI . Widget voorziet al in een mechanisme om die eenvoudige, die ik beschreven in het commentaar bij het vorige artikel te maken.

Widget maakt gebruik van de instantie eigendom _UI_ATTRS dat een object met twee andere eigenschappen, bevat SYNC en BIND . Elk van deze een array de namen van de configuratie attributen aanvankelijk gesynchroniseerd en vervolgens om de UI reflecterende huidige waarden behouden geluisterd. Widget verwacht dat elk van deze items een methode te hebben die ermee verbonden zijn, genoemd naar het attribuut naam voorafgegaan door _uiSet met de eerste letter van het attribuut naam omgezet in hoofdletters de methode naam hebben in de juiste kameel geval. Dus als "value" werd vermeld in elk van de _UI_ATTRS arrays (hetzij SYNC of BIND ) zou verwachten Widget een vinden _uiSetValue methode. Deze methode ontvangt twee argumenten, de value wordt ingesteld en de src van de verandering. Dit is de code voor onze Spinner _uiSetValue methode:

  _uiSetValue: function (value, src) {
     if (src === UI) {
         terug te keren;
     }
     this._inputNode.set (waarde, this.get (FORMATTER) (waarde));
 } 

Alle hoofdletters id's die u ziet in dit stukje code overeen met string-constanten verklaard elders, zodat de YUI compressor om zijn werk beter te doen. De methode, in principe, stelt de value HTML-attribuut in de <input> vak om de nieuwe ingestelde waarde, na te zijn geformatteerd. De verwijzing naar het tekstvak werd verstrekt door _locateNodes . De src argument is in eerste instantie gecontroleerd om te zien of op de tekenreekswaarde 'ui' . Indien dit zo is, wordt geen maatregelen worden genomen. Dit om te voorkomen eindeloze lussen. Als de gebruiker iets in het invoervak, wordt de waarde gaan in de value configuratie eigenschap die dan zou een brand valueChange evenement, dat zou krijgen _uiSetValue genoemd die, indien aangevinkt, dan zou gaan en verander de waarde van de input box, die zou leiden tot het hele proces opnieuw. Zo werd in _uiSetValue , als we weten de verandering komt van de UI, we doen niets en zo breken de lus. Dit vereist echter een ander stukje code elders. In de luisteraar voor de DOM event, als we de configuratie attribuut te stellen, gebruiken we de derde optioneel argument in te stellen, zoals deze:

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

Het is aan ons om ervoor te zorgen dat veranderingen die uit de UI zijn dus gemarkeerd en dan is dat dezelfde vlag te controleren aardlussen te vermijden. Gebruik maken van de identifier src bij het ​​instellen van de waarde van het attribuut, niet source die niet zal worden erkend.

Met al dit gezegd, heb ik nog niet gehad over de statische eigenschap _ATTRS_2_UI vermeld in de post van afdeling VI. Als de opmerkingen in mijn vorige artikel laat zien (via de blunders maakte ik in hen), ervoor te zorgen dat alle attributen die de UI goed staan ​​is een beetje rommelig. Je moet nooit te initialiseren _UI_ATTRS van de grond af, omdat Widget al somt een heleboel attributen en die verloren zou gaan. Je moet nieuwe attribuut namen samen te voegen in de bestaande, die enigszins is moeilijk te onthouden hoe je het goed doet. Om het simpel, zal MakeNode gelezen van de statische eigenschap _ATTRS_2_UI en doe dat aaneenschakeling voor u. Het zal al deze lijsten samen te voegen zodat van elke klasse in de erfenis keten op elk niveau voor elke categorie kan zijn eigen attributen te verwerken. In Spinner, hebben we:

  _ATTRS_2_UI {
     BIND: WAARDE,
     SYNC: VALUE
 } 

MakeNode accepteert zowel een reeks van namen of een enkel attribuut naam, zoals in dit geval.

De vraag is natuurlijk, waarom twee lijsten, een voor het binden van de andere voor het synchroniseren? SYNC wordt gebruikt de eerste keer, na de renderUI en bindUI methoden, als ze bestaan, worden genoemd en voor syncUI terwijl die vermeld in BIND zal zeker worden de overeenkomstige eigenschappen voor latere veranderingen. Heel vaak de SYNC array heeft minder vermeldingen dan de BIND lijst en dit komt omdat de template voor het onderdeel misschien al hebben precies dezelfde standaard waarde als de configuratie attribuut en er is geen noodzaak om een eerste synchronisatie te doen. Dus, als de standaardwaarde voor de value configuratie attribuut is een lege string en de <input> element in de sjabloon heeft geen value eigenschap, dan is er geen noodzaak om ze te synchroniseren op de initialisatie.

Attributen die in BIND hebben hun _uiSet Xxxx methoden in een willekeurige volgorde, als attributen kan ingesteld worden in willekeurige volgorde. Attributen die in SYNC zal een keer worden genoemd in de volgorde waarin ze vermeld staan ​​met die van de voorouders voor hun erfgenamen, dus als men afhankelijk van een ander (die dat niet zou moeten), de orde zou kunnen zijn van belang.

MakeNode zal controleren op dubbele items in een van deze arrays. Als er verschijnen, betekent dit dat een klasse onze component erft van al behandelt dit attribuut en elke nieuwe verklaring zal hoogstwaarschijnlijk over de schreef gaan _uiSet Xxxx handler voor. Overigens MakeNode controleert ook op dubbele vermeldingen in _CLASS_NAMES , die ook kan leiden tot conflicten in sommige, maar niet alle, omstandigheden. MakeNode schrijft een bericht naar de log voor dergelijke fouten.

De _PUBLISH woning

Ten slotte is de _PUBLISH zal statische eigenschap lijst van de gebeurtenissen die moeten worden gepubliceerd. Het bevat een hash met de naam van de gebeurtenis de toetsen en een voorwerp letterlijke configuratie eigenschappen als waarden. Zij zal alle gebeurtenissen die in een dergelijke zaak in alle overervingsketen. Dezelfde naam van de gebeurtenis kan worden gepubliceerd in een klasse en een klasse die overerft van het, waardoor de configuratie eigenschappen van latere degenen negeren van de oudere. Zo kan u een bestaande gebeurtenis uitzending wereldwijd te maken. Net als bij de _EVENTS goederen, omdat _PUBLISH een statische eigenschap zonder toegang tot this , bij het ​​specificeren functies is de naam van de werkwijze, als een string, dat moet worden.

Conclusie

MakeNode biedt een zeer eenvoudige template processor, met functionaliteit die sterk is geïntegreerd met de Widget Foundation Class. Het biedt ook helper methoden classNames maken voor gebruik in de mal die naam gebruik te lokaliseren en de gemaakte knooppunten verwijzen. Het biedt ook de middelen aan te sluiten naar de gebeurtenissen gegenereerd door zowel de UI en de component zelf en associëren elk met een methode. Het doet al deze dingen, en tegelijkertijd zorgen voor de erfenis keten te respecteren recht omhoog te Widget en elk niveau van de klassen kunt u definiëren.

Zij voorziet niet in voor absoluut alle mogelijkheden, maar bestrijkt een goede spreiding van hen. Toch hoeft het niet dat je van het toevoegen van extra functionaliteit. Je zou kunnen hebben zelden een schrijven bindUI of syncUI methode als u gebruik maken van de lijm door MakeNode, maar kunt u dit doen, omdat MakeNode geen gebruik van maken.

Als een bonus aan degenen die het geduld om zo ver, ik heb ook gewijzigd Anthony Pipkin's Button set van galerie componenten lezen en maakte een accordeon en TimeSpinner componenten, allemaal beschikbaar in de Galerij .

Over de auteur: Daniel Barreiro (scherm naam Satyam) is al geruime tijd. De ENIAC was uitgeschakeld op de dag voor hij geboren werd, dus hij gemist, maar hij heeft niet veel gemist sinds. Hij had een kans om ponskaarten, programma 6502 chips (denk aan de Apple II?), Eigen een TRS-80 en zie een aantal fantastische stukken van bedrijfsapparatuur in zijn geboorteland Argentinië, die misschien wel elders in musea. Als de globalisering de deuren geopend voor de wereld, zijn dan nauwelijks bruikbare Engels (plus een elektrotechnische opleiding) hem op de loopbaan, die eindigde in een 5-jarige baan in de Bay Area in de dagen van de NCSA Mosaic. Helemaal geïntrigeerd door de grappige krabbels een vriend van hem schreef in zijn platte tekst editor, vol <'s en>' s, hij eindigde het leren heel veel over de wereld van de front-end engineering. Het was een lange reis, omdat COBOL en Fortran. Nu woont hij heel gelukkig met pensioen is in de Middellandse Zee in de buurt van Barcelona, ​​Spanje.

Zoek gesprekken: Bloglines | technorati

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