Yahoo! Блог User Interface (YUIBlog)

Юи 3.4.0 Преглед на издаване 3 Сега на разположение на CDN

Екипът на Юи току-що завърши крайния спринт развитие, за освобождаване 3.4.0. По това време ние считаме кода функционално пълен. Ние планираме да прекарат следващата ни спринт, с акцент върху последния кръг на тестване и създаване на повече примери и документация. Ние са написали FC (функционално пълна) изграждане на CDN за Общността за проучване и обратна връзка. Можете да получите достъп тази версия http://yui.yahooapis.com/3.4.0pr3/build/yui/yui-min.js .

Има някои конкретни области на библиотеката, където ще се радваме да имаме обратна връзка на Общността:

• Loader е имал значителен ъпдейт за 3.4.0. Ако се прави ръчно спецификации за натоварване чрез use("*") или използването на submodule конфигурации, че високо ценим опитвате кода си с новия Loader, за да се уверите, ние правилно разглеждане на всички използването случаи. За по-подробна информация за Товарещи промени в тази версия, се обърнете към блог пост, описващ 3.4.0 Товарещи промени .
• Календар и панел са напълно функционални и готови за разработчик употреба.
• Графика: Има няколко промени API, които ще засегнат всеки експериментален код, написан на графика API, разпределени в Pr2 освобождаване getShape() е преименуван addShape() . Има също няколко атрибутни заместители.
• Преход: Местните преходи вече се поддържат в FireFox.
• WidgetButtons е била освободена като нов уиджет, който ви позволява да поставите CSS-стил бутони в горния и долния колонтитул на всяка джаджа, която реализира поддръжка на стандартния модул.
• Widget-модалността и Widget-автоскриване плъгини са превърнати в разширения.
• Widget: Добавена е поддръжка за да унищожи (вярно), която ще премахне и да унищожи всички деца възли (не само boundingBox и contentBox), съдържащи се в рамките на boundingBox джаджа. унищожават () ще запази сегашното си поведение, поради потенциално високо по време на изпълнение на разходите за унищожаване на всички деца възли. Ако ви унищожи Джаджи В своето заявление или потребителски разработчик джаджа, от вашата помощ при тестване на тази промяна ще бъде оценена.
• ScrollView поддържа вертикални пейджинг, включва един плъгин scrollview списък да добавите на СГО classnames на непосредствените елементи списък, както и няколко корекции на грешки и редакции
• App рамка: Искаме да се разшири, искрено ви благодаря за всички разработчици в общността, които са отделили време, за да тестват новата рамка App. Ние получихме отлична обратна връзка, след Pr2 освобождаване. Моля, да продължат да проучват тези компоненти и да ни изпратите вашите забележки и предложения.

Можете да получите допълнителна информация за съдържанието на тази версия, като преглед на историята на кумулативен и пълния списък на билети, разгледани в PR3 . Моля, подайте някой аксесоар искания, бъгове и регресии в билета база данни за YUILibrary.com .

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Юи: Работно време Четв 28 юли

Y.Calendar идва до 3.4.0

Календар е един от нашите по-популярни джаджи в Юи 2 семейни, и го прави своя дебют на Юи 3 архитектура в 3.4.0. Алън Рабинович е собственик и автор на компонента и ще бъде на поканата ни повторно въвеждане на този стар фаворит, показва някои нови подходи към проблемите, с които се сблъскват с 2.x Календар. Съм особено jazzed за подкрепа за интернационализация, но новите правила, според които също са доста завладяващ.

Хайде, и да си-за избор на дата, календар на събития, внос-от-дълбокото и да палачинки въпроси и заявки за функции с вас, като плът, сега и бъдеще Y.Calendar . (Не, не ще импортира ICAL, но ако някой иска да се създаде модул за галерията, за да се опитоми, че звяр, има със сигурност да бъде YUIConf билет за вас ;))

Ние сме обратно към обичайния си път през тази седмица, така че ние ще се видим в Свързване в 10am PDT.

Time & подробности

Ние ще бъдем онлайн от 10 до 11 часа PDT четвъртък. На връзката са същите, както обикновено.

1. Наберете да 1-888-371-8922 (Skype работи чудесно за неамерикански участници *)
2. Въведете участника код 47188953 #
3. Присъединете се към сесия за споделяне на екрана (това ще ви подкани да инсталирате плъгина на Adobe Connect, ако това е вашето първо време да го използвате)

Забележка: Тъй като това е една отворена линия на конференцията, молим, че обажданията да заглушите им линии, освен ако те не участват в активна дискусия.

* - Ако Skype не е опция, пишете ми или улов мен (ls_n) в IRC канал # Юи на FreeNode за местен номер.

Запис

Благодаря на всички за свикване! Онлайн запис на сесията е вече на разположение.

Високото качество, iPhone / iPad съвместими, за сваляне запис е тук .

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Юи: Работно време на чт 21 юли

А на DataTable актуализация и галерия витрина

3.4.0 освобождаване цикъл идва към своя край и ще бъдат опаковани с всички видове големи възможности, но говори ясно, DataTable не е намерила толкова развитие фокуса както трябва. Налице са някои корекции на грешки, макар и справедлива стойност на планиране за промените, които са насочени в 3.5.0, както и чудесно начало на участието на Общността с неговото развитие.

Ние знаем, че на DataTable е невероятно важна джаджа за много клиенти, така че ние разбираме цената на забавяне фокусирани развитие. Тази отворена часа ще бъде обновяване на каква работа ще се прави за 3.4.0, това, което е планирано за 3.5.0, и въвеждането на голяма работа, която е започнала да се появят в "Галерия", за да добавят функции и да коригират грешки за DataTable и семейството си за подкрепа на класи).

Ние ще бъдем на линия час по-рано тази седмица, за в полза на на Eamon Броснан (известен още като, mosen от # Юи), който, при условие редица Галерия петна, ние ще се търси. В противен случай, ще имаме други обитатели на # Юи и галерията сътрудници, които показват своите изделия. Ако имате решение на DataTable или работа в прогрес, които бихте искали да споделите, моля да ме уведомите за да мога да блокира график, за да се побере всичко (ls_n в # Юи или Twitter ).

Time & подробности

Ще бъде онлайн от 9am до 10am PDT четвъртък. На връзката са същите, както обикновено.

1. Наберете да 1-888-371-8922 (Skype работи чудесно за неамерикански участници *)
2. Въведете участника код 47188953 #
3. Присъединете се към сесия за споделяне на екрана (това ще ви подкани да инсталирате плъгина на Adobe Connect, ако това е вашето първо време да го използвате)

Забележка: Тъй като това е една отворена линия на конференцията, молим, че обажданията да заглушите им линии, освен ако те не участват в активна дискусия.

* - Ако Skype не е опция, пишете ми или улов мен (ls_n) в IRC канал # Юи на FreeNode за местен номер.

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Next-Gen YSlow Осъществено от Юи

Преди няколко седмици, Yahoo! обяви YSlow за мобилни устройства на Velocity 2011 , с което властта на YSlow анализ изпълнение на мобилния свят.

YSlow за мобилни работи като отметка , което прави възможно да се движат по други браузъри, отколкото Firefox (като добавка) или Chrome (като допълнение) .

Архитектурата на YSlow е частично преработени, за да работят по-платформа и Юи е съществен фактор в sandboxing, крос-браузър абстракция и на прост YQL достъп възможно.

Sandboxing

За да бъде вграден в страницата, без да се намесва с анализ на ефективността на и без да се обърква със самата страница, YSlow е една отметка, който инжектира JavaScript и CSS в която и да е страница, чрез повишаване на силата на Юи sandboxing:

Отметка URL:

 JavaScript: (функция (Y, P, о) {
     р = y.body.appendChild (y.createElement ("Iframe"));
     p.id = 'YSlow-отметка ";
     p.style.cssText = 'дисплей: няма ";
     O = p.contentWindow.document;
     o.open (). напиши ("
         <head>
         <Onload = "
             YUI_config = {
                 победа: window.parent,
                 DOC: window.parent.document
             };
             Var г = документ;
             d.getElementsByTagName (\ 'главата \ ") [0]
                 . AppendChild (
                     d.createElement (\ "скрипт \")
                 ). SRC = \ 'http://d.yimg.com/jc/yslow-bookmarklet.js \ "
         >
     ');
     o.close ()
 } (Документ))

Кодът по-горе:

• създава празен Iframe;
• добавя тя към страницата орган;
• скрива * Iframe ";
• получава прозорец манипулатор;
• пише в неговото съдържание тялото на вградена рамка;
• това тяло е празна, но има един onload събитие
• onload събитие определя как да инжектирате YSlow JS:
  • , определя YUI_config , така че win и на doc точки към страницата, се анализират window и document
  • динамично инжектира YSlow URL чрез създаване на script елемент в Iframe head

* Вградена рамка се показва по време на всички презентации YSlow активи са заредени

Това ще постави вградена рамка в страницата се анализират. Това Iframe ще действа като sandboxed среда, и YSlow ще да пребивават в него. Тъй като на Iframe е създаден динамично без src атрибут, то ще има достъп до майка (страницата се анализират), защото има не един и същ произход за нарушение на правилата, което се случва там.

В YUI_config обектът е удобен, защото тя определя win и doc майка Iframe (страницата се анализират), като по този начин всяка нова инстанция Юи ще бъде обвързана към майка документ по подразбиране, окабеляване всяка покана на Y.all и Y.one чрез Y.config.win или Y.config.doc от по Юи use обратно.

Представяне YSlow се обработва от Iframe window и document препратки, което позволява YSlow главния скрипт, за да се направи за маркиране, както и донесе външен CSS в рамките на този Iframe, без да влиза в конфликт с стилове майка. YSlow сканира майка страница, за да получите всички компоненти (изображения, скриптове, връзки, фон-изображение, флаш и т.н.), необходими за по-късно анализ на ефективността. Това се прави чрез достъп Y.config.win и Y.config.doc , тъй като те се отнасят към страницата майка.

Cross-браузър абстракция

Като една отметка, YSlow за мобилни устройства е трябвало да работят на всеки браузър *. Юи се абстрахира въпросите, свързани с различни браузъри, като нормализиране на браузъра различия, в резултат на чиста, лесна за четене и възможна за поддържане програмния код.

YSlow, не ​​е напълно пренесли до Юи 3 - само контролера слой, (от предстоящия компонент App) за сега - но все пак, всички DOM манипулация и обработка на събитие се извършва от node и event модули. В бъдещите версии, ние планираме да пренесете повече функции YSlow Юи 3.

* Не всички браузъри се поддържат в момента

YQL

YSlow анализира страници, като проверка на HTTP хедъри за компонентите, намерени на страницата. HTTP отговор заглавията за грешка не са налични в страницата, следователно тези компоненти трябва да бъдат поискани отново с цел за YSlow, за да получите информация заглавие отговор. Това може да се постигне, като се иска списък с URL адреси на компонент чрез XMLHttpRequest (AJAX), но за съжаление поради ограничение със същия произход политика , това не е възможно, освен ако всички компоненти са в същия домейн като на страницата, което е много малко вероятно.

Една обща заобиколно решение за ограничение на същия произход политика се използва JSONP, където работи като прокси иска списък от компоненти, URL адреси и извличане на HTTP заглавия на отговор от името на YSlow външен сървър. Поради популярността на YSlow и последните мобилни анализ на ефективността на усилията, ние очакваме доста тежък трафик за YSlow за Mobile отметка,. За да подкрепи такъв трафик, YQL е мащабируемо решение, прието от на YSlow чрез отворена таблица с данни, име data.headers , които извлича отговор горни и съдържание за даден списък с URL адреси, докато се представя за User-Agent, за да се гарантира, очаквано съдържание е възстановен.

Запитване на YQL компонент върши цялата работа на управление на YQL запитвания по време на управлението на JSONP заявки под капака, което прави контролера YSlow код много по-прости и лесни за поддръжка.

Бъдещи подобрения: Нова YSlow за мобилни приятелски интерфейс

В момента на YSlow за мобилния потребител опит е същата, както на работния плот опит. Справяне с дълъг списък на данни за резултатите от анализи, не е най-добрият опит на малки екрани смарт-телефони. От Юи абстрахира кръстосано устройство жестове , YSlow за мобилни устройства ще получи чисто нов мобилен лесен интерфейс в бъдещите версии.

Извършване на изпълнение инструмент

На YSlow за разгръщане Mobile е направена внимателно от гледна точка на ефективност на въздействие върху времето за зареждане на страницата се анализират. Юи 3 модула, които се използват за YSlow са били проверявани, за да бъдат включени само модулите, необходими, за да заредите YSlow възможно най-бързо. Семето Юи файл и Loader не бяха включени, тъй като всички необходими модули и submodules, са комбинирани заедно, Райън Grove за изпълнение на Дзен съвети, които направиха възможно да се зареди всичко заедно в един малък една молба: YSlow bookmarklet.js: 204KB, 66KB ( GZIP), където:

• На Юи: 75KB, 27KB (GZIP)
• YSlow: 129KB, 39KB (GZIP)

Повече за YSlow

Бъдете постоянно в течение за дата с най-новите обяви YSlow:

• Посещение на обновения YSlow страница в getyslow.com,
• Обич YSlow във Фейсбук: facebook.com / getyslow
• След YSlow на Twitter: twitter.com / getyslow

За автора: Марсел Дюран е предната Водещ край за Yahoo! е изключителен екип Performance. Той е в изпълнение на оптимизация на уеб сайтове трафик в Yahoo! Front Page и екипи Търсене, където иска и изследвани уеб изпълнение на най-добрите практики за вземане на страници, дори по-бързо. Той е посветен на YSlow и други показатели инструменти за развитие, проучвания и евангелизъм. Неговата цел е да направи работата в интернет по-бързо, отколкото тя може да бъде и счита, че няма такова нещо като "само няколко милисекунди няма да боли".

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Сортирани актуализация на браузъра поддръжка

ГБС Промени

Конкретни промени за тази актуализация включват:

• Вече не възлага опит клас
• Преустанови предписването на специфични операционни системи (с изключение за мобилни устройства)
• Добавена покритие за Internet Explorer 9
• Добавена покритие за Firefox 4. †
• Добавена покритие за Firefox 5. †

Забележки:

• Символът на кама (като в "Firefox 4. †") показва, че най-ток-бета версия на ниво този клон получава подкрепа.
• Не се дава насоки на IOS или използването на Android OS устройство. Препоръката е, че можете да изберете устройствата, които са най-представител на потребителска база за всяка OS.

Премахване на оценките от изходно Browser Test

Това издание на ГБС актуализация представлява отклонение от нашите предишни актуализации, в това, че ние се движат далеч от картографиране браузъри директно опит степени (например "А-клас" и "C-клас"). Вместо да предписват това, което потребителите е уместно, за които браузъри, ние ще се фокусира върху определяне на ефективна стратегия за базовата линия тест, който максимизира тест покритие и намалява повърхността за изпитване. Например, IE6 все още значителни глобални пазарен гарантира продължиха тестване; ГБС обаче днес позволява за IE6 опит потребител да бъде различен от опита IE9.

Премахването на операционни системи от базовите Browser Test

За да се рационализират тестване и свеждане до минимум на изискванията по отношение на средствата, ние вече не уточни коя операционна система трябва да се тестват. Единственото изключение е, когато браузърът е плътно съчетание с версия на операционната система, в който случай ние се позоваваме на версия на операционната система, а от версията на браузъра (например "Safari IOS 4"). Това позволява да се съсредоточи покритие на теста версии на браузъра, и свеждане до минимум redudant тестване различни платформи. Въпроси, свързани със същия браузър в цяла версии са незначителни, и като цяло са свързани с по-високо ниво различия OS, като ключов работа и наличните шрифтове. Код, който е известно, да се докоснете до междуплатформени въпроси трябва да бъдат тествани като много платформи, като е възможно, но това тестване като цяло могат да бъдат изолирани на конкретни въпроси, а не работи на пълен тест на регресия на всички функции. Препоръчваме изравняване операционна приоритет тестване на системата с потребителското си база.

Защо е IE6 все още в списъка?

IE6 все още има достатъчно значителен дял на световния пазар, за да се обоснове проверени приемливо потребителски опит. Една обща погрешно схващане, с постепенното Подобрение стратегия е, че след браузър влиза "C-клас", че се превръща в "не се поддържа", когато в действителност това всъщност означава, че трябва да бъдат доставени на HTML само опит. Сега, когато вече не предписват, които браузъри получават какъв опит, това е оставено за проекти, да се реши въз основа на своите потребители и ресурси. ГБС се фокусира върху уточнява кои браузъри се нуждаят от проверени използваема опит, въз основа на фактори като пазарен дял и влияние. Да определят какво е "използваем", и които описват приемливи нива на разграждане са оставени за екипи, които да решат. Ние все още насърчаване на проста Progressive аксесоар модел, и да попречат на проекти от създаването на нови нива, без отчитането на допълнителните разходи в областта на развитието, на изпитване, и поддръжка ресурси.

ГБС Прогноза

Очакваме да се направят следните промени в следващата актуализация на:

• Прекратите покритие за Safari на IOS 3.
• Добави покритие за Webkit на Android 3.
• Добави покритие за Firefox 6.
• Добави покритие за Safari IOS 5.

ГБС Архив

• Актуализация на ГБС, 3.11.2010
• Актуализация на ГБС, 16.02.2010
• Актуализация на ГБС, 10.16.2009
• Актуализация на ГБС, 02/07/2009
• Актуализация на ГБС, 28.1.2009
• Актуализация на ГБС, 7.3.2008
• Актуализация на ГБС, 19.02.2008

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

Widget Разширяване "MakeNode"

Бележка на редактора: Тъй като тази статия е публикувана, модула MakeNode е бил публикуван, за да Галерия Юи и получи някои подобрения. Моля, обърнете се към актуализираната статия, Актуализирано: Widget "MakeNode", Удължаване .

В предишната ми статия, рецепта за 3 Заявление Юи , показах начин за използване на Y.substitute като един много основен шаблон процесор. Идеята отнел живота от там, с предложения от хора в IRC канал # Юи, и аз направих една Widget разширение, което е на разположение на моя сайт, наречен MakeNode . MakeNode не е родово процесор шаблон и не се разбира като едно цяло. От друга страна, тя е тясно интегриран с Юи Widget фондация клас, включително клас и събитие помощници и интернационализация. В тази статия, аз ще се на Spinner например и да го променят, за да следват насоките от предишната ми статия и да използват MakeNode. Модифицираният на Spinner компонент ( JS , CSS , спрайтове ), както и един пример от моя сайт. Връзки към допълнителни ресурси могат да бъдат намерени в края на тази статия.

Разширяване компоненти

След MakeNode е заредена, вие трябва да се включи модул си YUI().use() изявление с името 'makenode' . Тогава, за разширяване на обсега на джаджата, да я списъка в третия аргумент Y.Base.create() , като този:

  Y.Spinner = Y.Base.create (
      "Spinner",
      Y.Widget,
      [Y.MakeNode],
      {
         / / Например членовете на ...
      }
      {
          / / Статични членове
      }
 ); 

Можете да добавите MakeNode заедно произволен брой подходящи разширения за джаджа, като WidgetParent, WidgetChild, WidgetStdMode и др. MakeNode добавя две-защитени методи, _makeNode и _locateNodes, и той ще прочете от няколко статични свойства, ако се открие.

Всички членове на това разширение са защитени или частни, тъй като те са предназначени да бъдат използвани от разработчик на компонента, а не от ОСЪЩЕСТВЯВАЩА използването на тези компоненти, които не трябва да се занимава с тях.

Дефиниране на шаблон

Първото нещо, което ще правите обикновено е да се определят шаблона за вашия компонент. За на Spinner нашата шаблон ще бъде:

  _TEMPLATE:
     "<input Type="text" title="{s input}" class="{c на input}">",
     "<button Type="button" title="{s up}" class="{c up}"> </ бутон> ',
     "<button Type="button" title="{s down}" class="{c down}"> </ бутон> '
 ]. Се присъединят ('\ n'), 

Шаблонът по подразбиране обикновено ще бъде назован _TEMPLATE и декларирани по другите статични свойства на класа, като ATTRS . MakeNode ще използвате този шаблон, ако никой друг не е изрично предвидено. Шаблонът е изработен от обикновен HTML плюс серия на контейнери, затворени в къдрави скоби, изработени от един символ (преработка код) и последван от един или повече аргументи. Контейнери и това, което произвеждат, са:

• {@ attributeName} конфигурация атрибут стойност

• {p propertyName} например стойността на имота

• {m methodName arg1 arg2 ….} връщаната стойност на даден метод. Обработката код е последвано от метода име и произволен брой аргументи, разделени с интервал. Strings трябва да бъде затворен в двойни кавички. Номера, Булев тип и null ще бъдат преобразувани от низ към своите собствени типове данни

• {c classNameKey} CSS име на класа, генерирани от на статично собственост на _CLASS_NAMES

• {s key} низ от атрибут на strings , използвайки key , тъй като под-атрибут.

• {? other placeholder } произвежда низ checked когато в резултат на обработката на останалата част от контейнера е вярно.

• {} друга стойност, ще бъдат обработени точно като Y.substitute прави.

Например, {@ value} ще превежда към this.get('value') докато {p value} превежда this['value'] .

{m} контейнер е малко по-сложна. Първият аргумент след по m обработка код е името на метода и на останалата част от аргументите, всички, разделени с интервал, които ще бъдат предадени на даден метод. Тези аргументи могат да бъдат числа, null , true , false или низове, заградени в двойни кавички. Ще ги анализира MakeNode и да ги конвертирате своите собствени видове, като по този начин {m myMethod 123.45 true “this is a string”} ще доведе до, призовава this.myMethod(123.45, true, “this is a string”) така че първите два аргумента се превръща в тяхното правилно типове данни и низ може да съдържа интервали. За да включите двойни кавички, използвайте \\" , двойно обратно наклонена черта се изисква, тъй като JavaScript ще тълкуване на един и да го изхвърля, преди да стане да MakeNode. Само двойни кавички са позволени, MakeNode не използва eval() така че парсера се ограничава но безопасно. всичко друго, но не числа, null , Булев тип и двойни низове в кавички, ще бъдат игнорирани.

{?} контейнер е удобно да се използва с отметки и радио бутони. Тя ще произведе низ “checked” в зависимост от истинната стойност на инструкция за обработка код, който следва. Така <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/> ще произвежда значително отметка, ако getLength метод връща всичко друго, но нула. {?} ще приеме някое от другите контейнери, въпреки че тя има смисъл само с първите три.

За {c} контейнер, ние трябва да имат определени _CLASS_NAMES собственост.

Допълнителни контейнери могат да се добавят да MakeNode като ги добавите в _templateHandlers хеш.

_CLASS_NAMES Собственост

Заедно с ATTRS и _TEMPLATE статични качества, можем да определят едно _CLASS_NAMES собственост, която сочи към масив от низове. Всяка от тези струни ще бъдат използвани за генериране на име на класа. Така _CLASS_NAMES: ['input'] ще произвежда име на класа “yui3-spinner-input” . И Тези classNames се съхраняват в инстанция собственост this._classNames . {c input} контейнер в шаблона по-горе, ще бъде заменен от “yui3-spinner-input” .

Можете да използвате на _CLASS_NAMES собственост, за да генерира произволен брой classNames, дали да ги използвате в шаблон или не. Вие все още може да достигне до тези допълнителни classNames в рамките this._classNames . Име на класа се генерира на yui3 представка, следвана от стойността на NAME статично собственост, се обърна с малки букви, а след това на низ в _CLASS_NAMES (този, последният не ще се превърнат в малки букви), разделени с тирета. _classNames хеш също така ще съдържа на classNames за boundingBox и contentBox , първо под "." ключ и на второ място във “content” . Widget възлага на boundingBox classNames, получени от стойностите на NAME собственост на всеки от класовете в наследството верига, започвайки с yui3-widget . MakeNode магазини в this._classNames само най-отгоре на клас на boundingBox .

Ако компонент е на няколко нива, далеч от Widget, като SuperSpecialSpinner наследи от SuperSpinner която се наследява от Spinner който наследява Widget, и, ако някой или всички от тях имат _CLASS_NAMES свойства определени, MakeNode ще произвежда classNames за всички тях и да ги съхранявате в this._classNames . Не е нужно да се включи на всяко ниво, имената, които вече са обявени в предишните нива. В действителност, тя е по-добре, че не, тъй като classNames, произведени на всяко ниво ще използва стойността на NAME на това ниво. Така, в SuperSpecialSpinner , {c input} все пак ще доведе до “yui3-spinner-input” и не “yui3-superspecialspinner-input” и така тя ще продължи да ви CSS файл все още валидни.

{} Контейнер

Widget има strings конфигурация, определени атрибут, въпреки че не се инициализира с никаква стойност. Този атрибут е предназначена да държи на низове, които се виждат (или чрез екранни четци, прочетете) потребителят. Важно е, че никога няма да са видими струни директно в шаблона. Това не е изискване на MakeNode - никога не е била добра идея изобщо. Всички низове, които трябва да бъдат разглеждани или да прочетете на потребителя, трябва да винаги да се поставят в strings атрибут. strings атрибут съдържа хеш, където се намира всеки отделен текст от ключовата му. Spinner компонент има следните низове, които можете да видите, използвани в шаблона по-горе.

  низове: {
     стойност: {
         вход: "Натиснете стрелката нагоре / надолу за малки стъпки, страница нагоре / надолу за големи стъпки."
         нагоре: инкрементирате ",
         надолу: "Декремент"
     }
 } 

Най-добрата част за това е, че компонентите могат да бъдат локализирани на други езици много лесно от разработчиците, които използват компоненти. При създаването на копие на Spinner, можете да направите:

  Var mySpinner = нов Spinner ({низове: Y.Intl.get (Spinner ')}); 

Настройка на конфигурационните атрибут strings по този начин замества стандартните strings стойности с тези от езиковия файл ресурс, с помощта на предварително дефинирани език. {s} контейнер достъп до струните, които се съхраняват в strings атрибут, нито подразбиране или преведените, ако е зададено. {s xxxx} контейнер, в действителност, е нищо повече от един пряк път към {@ strings.xxxx} контейнер. Въпреки това, първото може само достъп до струните на най-високо ниво, като например, {@ strings.xxxx.yyyy.zzzz} ще ви даде достъп до низ дълбоко надолу.

Използването на _makeNode в renderUI

Ние използваме шаблон за създаване на маркиране за нашия компонент. За да направите това, ние можем да се обадите метод на MakeNode на _makeNode , като този:

  renderUI: функция () {
     . this.get ("contentBox"), добавяне (this._makeNode ());
 } 

Това ще запълни в на contentBox на нашата джаджа с маркиране от обработката на шаблона. _makeNode метод връща инстанция на Y.Node които могат да бъдат прикрепени или се добавя никъде или просто се държат по-късна употреба. Той не се връща низ, тя произвежда една Node например.

_makeNode метод отнема два незадължителни аргумента: справка за шаблон и обект, за да попълните в контейнери,, като Y.substitute . В нашия прост пример Spinner има един шаблон за цялата джаджа, но други джунджурии може да изисква от битове и парчета, направени от няколко шаблона. В този случай, обикновено наричаме _makeNode без аргументи за основната част и отново го наричат ​​с различни шаблони, за да попълните в допълнителните части. Примерът съдържа този renderUI метод:

  renderUI: функция () {
     VAR fieldset = this._makeNode ();
     this.each (функция (елемент) {
         fieldset.appendChild (this._makeNode (MultipleTemplates.RADIO_TEMPLATE, т.));
     });
     this.get ("contentBox"), добавяне (fieldset).
 } 

Първата покана към _makeNode връща Node например, се съхранява в променливата fieldset . Пробата компонент, също се удължава с Y.ArrayList така че RADIO_TEMPLATE ще бъде изпълнен със стойности, взети от предмети, съхранявани в списъка на масива и възли, приложени към fieldset преди тя да бъде най-накрая приложени към contentBox . Специални контейнери, като например {@} или {p} все още ще се отнасят за качества или свойства в основния обект. Вложените елементи ще бъдат обработвани точно както Y.substitute би.

Метод _locateNodes

MakeNode предвижда по-нататък, метода една _locateNodes който ще се опита да намерите всички елементи с на classNames декларирани в _CLASS_NAMES . За да намерите конкретни елементи, които могат да преминат произволен брой ключове за име на класа, в противен случай, _locateNodes опитва всички тях. За всеки елемент намерени на всеки име на класа, _locateNodes ще произвежда частна собственост например с помощта на долна представка, следвана от ключовото име и суфикс “Node” . Така в нашия Spinner например, _locateNodes ще генерира на имоти _inputNode , _upNode и _downNode . Ако няколко елемента имат едно и също име на класа, _locateNodes ще се върне препратка към първия от тях. Ако един елемент не е намерен, не променлива ще бъде създаден.

, На Spinner компонент ние използваме _locateNodes след създаването на маркиране:

  renderUI: функция () {
     this.get (CBX) добавяне (this._makeNode ());
     this._locateNodes ();
 } 

_EVENTS Статичен собственост

Още едно свойство може да бъде определен по линиите на _TEMPLATE и _CLASS_NAMES и че е _EVENTS . _EVENTS ще съдържа хеш на ключове името на класа, всяка от които съдържа хеш на събитието видовете и начините да се справиш с тях. Тя е по-добре да се обясни с пример:

  _EVENTS: {
     '.': {
         ключ: {
             Fn: _onDirectionKey ",
             аргументи: ((Y.UA.opera) "надолу": "Press:") + "38, 40, 33, 34"
         }
         mousedown: "_onMouseDown"
     }
     "...": {
         mouseup: "_onDocMouseUp"
     }
     вход: {
         промяна: "_onInputChange"
     }
 } 

_EVENTS е обект (хеш), с произволен брой свойства. Имената на имотите, което означава, че ключовете на хеша, да идентифицира елементите, чиито събития, ние ще слушате. Те са същите идентификатори, използвани в _CLASS_NAMES . Има две допълнителни специални клавиши "." и ".." . Докато клавишите на име на класа се отнасят за елементи, вложени в рамките на contentBox "." Ключът се отнася до на boundingBox себе си, докато ".." се отнася до документ, съдържащ тази джаджа. Мислете за тях като прави chdir команда, когато се намира в boundingBox ниво. _EVENTS собственост се обработват, след методи renderUI , bindUI и syncUI са били наричани така че джаджа се очаква да вече да е поставена в тялото на документа, в противен случай ще се провали. ".."

Всеки един от записите в _EVENTS е един допълнително обект, че използвате вида на събитието като си ключ и името на един метод, например да се справя. _EVENTS , е статична променлива, има никакъв достъп към this , така че тя не може да вземе действителните препратки функция, само името на метода на събитие слушател. Някои типове събития се нуждаят от допълнителни аргументи, като key събитие. В този случай, вместо за предоставяне на името на събитието манипулатор може да осигури един обект с имоти fn и args да държи на името на функцията и допълнителни аргументи, когато е необходимо.

MakeNode ще използва Node.delegate да слушате събитията на вложените елементи, докато ще използва Y.on да слушате на събития от boundingBox и тялото на документа. (Забележка: слушане на key събитие на всеки вложен елемент работи само с на версия 3.4.0pr1 и повече, тъй като делегацията на key . събитието не бе на разположение преди всички други функции, работят с предишните версии, както и)

_EVENTS декларации са кумулативни,, когато компоненти наследи една от друга. Всеки клас в наследството верига ще има своя _EVENTS декларация обработват отделно.

_ATTRS_2_UI Статичен собственост

Събития вървят в двете посоки, от потребителския интерфейс на компонента и от компонент на потребителския интерфейс. Първият се обработват от _EVENTS собственост. Тогава там са събитията, уволнен от промени в стойността на атрибут, които трябва да бъдат отразени в потребителския интерфейс. Както споменах и в предходния член, когато има някакви вторични ефекти от промяна на конфигурацията атрибут, те трябва да се обработват от слушателите на климата събития, а не от допълнителен на setter метод на атрибута, което трябва да се занимават само с нормализиране на стойността се определя. Потребителският интерфейс трябва да отразяват състоянието на конфигурационните атрибути, на първо място в syncUI , когато се инициализира и след това на всеки случай на промяна на атрибут. За последното, ние трябва да се приложи слушател събитие, което ние правим в bindUI . Widget вече предвижда механизъм, който да прави толкова просто, който описах в коментарите към предишната статия.

Widget използва инстанция на собственост _UI_ATTRS който съдържа един обект с два допълнителни свойства SYNC Синхронизация и BIND . Всяка от тях е масив списък на имената на конфигурационните атрибути, които трябва да бъдат първоначално synched и след това слушах, за да запази потребителския интерфейс, който отразява текущите стойности. Widget очаква всеки един от тези записи, за да има метод, свързан с него, на име след име на атрибут,, представка от _uiSet с първия знак от името на атрибута, конвертирани с главни букви името на метода в правилното камила случай. Така, ако "value" , посочени в някоя от масиви на _UI_ATTRS или SYNC или BIND ), Widget да се очаква да се намери метод _uiSetValue . Този метод ще получите два аргумента, value се определя и src на промяната. Това е кодът за нашия Spinner _uiSetValue метод:

  _uiSetValue: функцията (стойност, SRC) {
     ако (SRC === UI) {
         се върне;
     }
     this._inputNode.set (стойност, this.get (форматиране) (стойност));
 } 

Всички главни идентификатори, които виждате в тази част от кода съответстват на низови константи, обявени на друго място, за да позволи на Юи компресор, за да си свърши работата по-добре. Методът, по същество, определя value HTML атрибут в <input> кутия за нов набор стойност, след като е бил форматиран. Позоваването на текстовото поле е предоставена от _locateNodes . src аргумент първоначално се проверяват, за да видите, ако на низовата стойност 'ui' . Ако това е така, да не се предприемат действия ще бъдат предприети. Това е, за да се избегне безкрайното електрически вериги. Ако потребителят въведе нещо в полето за въвеждане, нейната стойност ще отиде в value атрибут конфигурация, която след това ще огън, едно valueChange събитие, което би се _uiSetValue призовани, които, ако не бъдат, тогава ще отида и да промените стойността на полето за въвеждане, които ще предизвика отново целия процес. Така в _uiSetValue , ако знаем, промяната идва от потребителския интерфейс, което правим нищо и така се прекъсне веригата. Това обаче изисква друга част от кода на друго място. В слушател за събитието DOM, когато ние поставихме конфигурация атрибут, ние използваме третия допълнителен аргумент да се определят, като това:

  _afterValueChange: функция (EV) {
     this.set (VALUE, ev.newVal {SRC: UI});
 } 

Това е за нас, за да се гарантира, че промените, идващи от потребителския интерфейс са маркирани по този начин и след това да се провери дали едно и също знаме, за да се избегне примки.

С всичко това каза, аз не са все още споменава статичен собственост _ATTRS_2_UI , посочени в заглавието на този раздел. Тъй като коментарите в предишните ми показва статия (чрез гафове, направени в тях), като се уверите, че са надлежно описани всички атрибути, които оказват влияние върху потребителския интерфейс е малко разхвърлян. Никога не трябва да се инициализира _UI_ATTRS от нулата, тъй като Widget вече са изброени един куп от атрибути, както и тези, които ще бъдат загубени. Трябва да се слеят нови имена на атрибут над съществуващите, което е малко трудно да си спомните как да го направя така. За да го прости, MakeNode ще прочетете от статично собственост _ATTRS_2_UI и че конкатенация за вас. Тя ще слеят всички тези списъци от всеки клас в наследството верига, така че на всяко ниво всеки клас могат да се справят собствените си качества. В Spinner, имаме:

  _ATTRS_2_UI: {
     BIND: стойност,
     Sync: стойност
 } 

MakeNode ще приеме набор от имена, или едно име на атрибут, тъй като в този случай.

Естествено възниква въпросът, защо два списъка, за да обвърже за синхронизиране? Доста често на SYNC масив има по-малко допълнения от списъка на BIND и това е, защото шаблона за компонент може би вече имат почти същата стойност по подразбиране, като атрибут на конфигурацията и там е необходимо да се прави първоначален синхронизиране. Така че, ако стойността по подразбиране за value на атрибут конфигурация е празен низ и елемент на <input> в шаблона има никаква value атрибут, а след това там не е необходимо да ги синхронизира от инициализация.

MakeNode ще проверява за дублирани записи в някоя от тези масиви. Ако някоя се появи, това означава, че един клас нашия компонент наследява вече обработва този атрибут и всяка нова декларация, най-вероятно прекрачи _uiSetXxxx манипулатор за него. Между другото, MakeNode също проверява за дублирани записи в _CLASS_NAMES , които също могат да предизвикат конфликт в някои, макар и не всички, обстоятелства. MakeNode ще напишете съобщение до дневника за всяка такава грешка.

Заключение

MakeNode осигурява много прост шаблон на процесор, с проста функционалност, която е силно обвързана с класа Widget фондация. Той също така предвижда помощни методи, да създават classNames, да бъдат използвани в шаблона и да използват тези имена, за да се локализират, създадени възли. Той също така предоставя средства, за да кука в събитията, породени както от потребителския интерфейс и самия компонент и се сдружават с метод. Той прави всички тези неща, докато се грижи за спазване на веригата наследство направо до притурка и всяко ниво на класове, които могат да въведат уточнения.

То не съдържа абсолютно всички възможности, но обхваща добър набор от тях. Въпреки това, не ви лишава от добавяне на допълнителна функционалност. Рядко може да се наложи да пиша метод един bindUI или syncUI ако използвате лепило, предоставена от MakeNode, но можете да го направите,, тъй MakeNode не ги използва.

Като бонус на тези, които имаха търпението да четат толкова далеч, аз също са променени Антъни малко пръстено гърне на бутона набор от компоненти за галерия:

• button.js
• button.css
• бутон group.js
• бутон group.css
• background.png
• фон-active.png
• Icon-sprite.gif
• пример

API документи могат да бъдат намерени тук .

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!

На Юи и Loader промени, за 3.4.0

В 3.4.0 ние започнахме процеса на преместване на някои от логика Loader наоколо, за да не само да по-performant, но да се направи по-силен и по-лесно да се използва в други места (например на сървъра). Ние ще се подвижен повече промени в бъдещи преразглеждания, но аз исках да отнеме известно време и да обясни какво е променено, защо той бе променено и как тя може да повлияе на разработчиците. За голямата част от случаите на използване, разработчиците ще забележите нищо по-различно, с изключение на това, че нещата са малко по-бързо и техните изисквания са малко по-малък.

Семената на файла

Първото нещо, което искате да се обърнете е на семена Юи файл. В предишните версии на Юи, нашата семена файла е много малка и не съдържа Loader или някоя от мета-данни. Ние открихме, че в 90% използване случай това не е като performant, както се надявахме. Нормален потребител включва семена на файла, след което иска техните модули, което от своя страна означава, че семената трябва първо да донесе Loader, след това изчислява всички негови зависимости, а след това донесе на всички тях. Сега чувствам, че това допълнително искане HTTP е грешното нещо, което трябва да направите, така че нов стандартен файл семе съдържа товарач и мета-данни. Да, това ще направи първоначалното искане малко по-голям, но той ще направи за зареждане на модули, които много по-бързо, тъй като всички на своите изисквания за мета-данни, са вече на страницата.

Ако желаете да го използвате по стария начин, може просто да включва семена Юи база файл вместо. 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. Например:

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

The Future

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.

Вижте разговори: Bloglines | Technorati

Споделете и разширяване : Запазете си отметка към del.icio.us | Digg тя | Reddit!