YUI的3.4.0預覽版現已在CDN

12:39 2011年7月28日，由喬治·帕克特| 開發 | 4評論

YUI團隊剛剛完成的最終發展為3.4.0版本的衝刺。 在這個時候，我們考慮功能完整的代碼。 我們計劃用我們的下一個衝刺，專注於我們的測試和創造更多的例子和文檔的最後一輪。 我們已經發布了一個FC（功能​​）建立完整的社區勘探和反饋的CDN。 你可以訪問這個版本http://yui.yahooapis.com/3.4.0pr3/build/yui/yui-min.js 。

庫有一些特別的地方，我們很想有社區反饋：

  • 裝載機有重大更新為3.4.0。 如果你正在通過手動負載規格use("*")或利用子模塊的配置，我們會非常感激你想你的代碼與新的Loader，以確保我們正確處理所有的用例。 如需對本新聞稿中的裝載機變化的詳細信息，請參閱博客文章描述3.4.0裝載機變化 。
  • 日曆和面板是全面的功能和開發利用的準備。
  • 圖形：已經有幾個API的變化，會影響任何實驗分佈在PR2的釋放圖形API編寫的代碼getShape()已更名為addShape() 也有幾個屬性的替代品。
  • 過渡：母語轉換現在在Firefox支持。
  • WidgetButtons已經發布了一個新的Widget擴展，它允許你把任何部件，實現了標準的模塊支持在頁眉和頁腳“CSS樣式”按鈕。
  • 已轉換為擴展部件的形態和 Widget 自動隱藏插件。
  • 部件：為破壞的增值支持（真），這將刪除並銷毀所有子節點（不只是boundingBox的和contentBox）內Widget的boundingBox的中。 destroy（）方法，將維持其目前的行為，由於潛在的高運行時間銷毀所有子節點的成本。 如果你破壞您的應用程序部件，或者是一個自定義部件開發，幫助您在測試這種變化，將不勝感激。
  • 滾動支持垂直分頁，包括滾動的列表插件添加CSS類名直接列表元素，以及一些bug修復和重構
  • 應用程序框架 ：我們要擴展一個真誠的感謝你在社會上的人已採取的時間來檢驗推動新的應用程序框架的開發。 我們已經收到了極好的反饋後，PR2的釋放。 請繼續探討這些組件，您的意見和建議發送給我們。

你可以得到更多信息，本新聞稿的內容審查歷史匯總 ，並在蛋白酶處理門票的完整列表 。 請文件中任何的增強請求，錯誤和回歸的票YUILibrary.com數據庫 。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

銳：營業時間週四7月28日

7月25日下午10:56 2011年由盧克·斯密在發展 ，營業時間 | 2評論

Y.Calendar即將到3.4.0

日曆是我們更受歡迎的YUI 2家族的部件之一，它在3.4.0上YUI 3架構亮相。 艾倫拉比諾維奇組件所有者和作者，並會重新引入我們這個老喜愛的呼叫，顯示2.x的日曆所面臨的問題，一些新的方法。 我特別是飲譽國際化的支持，但新的渲染規則也很迷人。

來吧，並把您的日期選擇器，日曆事件，進口從iCal中，使煎餅的問題和你的功能要求，為我們的肉，現在和未來的Y.Calendar 。 （不，它會不會導入i​​Cal中，但如果有人想創造一個畫廊模塊馴服野獸，還有肯定是你YUIConf票;)）

我們又回到了本週我們平時的時間，所以我們會看到你將在上午10時PDT。

時間及詳情

我們會從上午10點至11點PDT星期四線上。 連接的詳細信息和往常一樣。

  1. 撥號到1-888-371-8922（Skype的非美國與會者*）
  2. 輸入與會者代碼47188953＃
  3. 加入屏幕共享會話 （會提示你安裝的Adobe Connect插件，如果這是您第一次使用）

注 ：因為它是一個開放的會議行，我們要求，來電靜音線 ，除非他們在積極討論參與。

* - 如果Skype是不是一種選擇，給我發電子郵件或在freenode上的＃YUI IRC頻道趕上我（ls_n）一個本地電話號碼。

錄音

感謝大家在調用！ 現在可以在線錄製會議的 。

高品質的iPhone / iPad兼容，下載的記錄是在這裡 。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

銳：週四7月21日營業時間

2011年7月19日，在2:16上午由盧克·斯密| 開發 ， 開放時間 | 12評論

一個DataTable更新和畫廊展示

3.4.0發行週期接近尾聲，並將於擠滿各種強大功能，但說白了，DataTable中已經沒有得到它應該有盡可能多的發展重點。 已經有一些錯誤修復，雖然，相當數量的規劃3.5.0針對性的變化，以及社區參與其發展的一個很好的開始。

我們知道，DataTable是一個極其重要的部件很多客戶，所以我們了解拖延重點發展的成本。 這將是營業時間為3.4.0更新完成什麼工作，什麼計劃3.5.0，畫廊開始興起，以增加新的功能和修正錯誤的DataTable（和偉大的工作，這是引進其家庭支持類）。

我們將在線造福埃蒙·布魯斯南（又名，從＃YUI mosen）的，誰提供一些畫廊的補丁，我們將看一個小時本星期早些時候 。 否則，我們將有其他的＃YUI的居民和畫廊展示他們的產品的提供者。 如果你有一個DataTable的解決方案或正在進行的工作，你想與大家分享，請讓我知道這樣我就可以阻擋的時間表，以適應一切（＃YUI或ls_n 嘰嘰喳喳 ）。

時間及詳情

我們會從上午9時至週四上午10時PDT在線。 連接的詳細信息和往常一樣。

  1. 撥號到1-888-371-8922（Skype的非美國與會者*）
  2. 輸入與會者代碼47188953＃
  3. 加入屏幕共享會話 （會提示你安裝的Adobe Connect插件，如果這是您第一次使用）

注 ：因為它是一個開放的會議行，我們要求，來電靜音線 ，除非他們在積極討論參與。

* - 如果Skype是不是一種選擇，給我發電子郵件或在freenode上的＃YUI IRC頻道趕上我（ls_n）一個本地電話號碼。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

下一代YSlow的供電由銳

7月18日，2011馬塞爾·杜蘭在下午09:17 | 發展 ， 性能 | 4評論

幾個星期前，雅虎宣布2011年在速度 YSlow的移動 ，使移動世界YSlow的性能分析的力量。

YSlow的手機作為作品的bookmarklet ，從而有可能比其他瀏覽器火狐（附加）或鉻（擴展）運行。

YSlow的建築部分被重新設計，以跨平台和YUI在沙盒，跨瀏覽器的抽象和簡單的YQL的訪問可能是重要因素。

沙箱

為了不干擾，不搞亂頁面本身的性能分析和嵌入在頁面上，YSlow的是一個bookmarklet，JavaScript和CSS注入任何網頁，利用YUI的沙箱電源：

書籤網址： 

 JavaScript的：（函數（Y，P，O）{
     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 *;
  • 得到它的窗口句柄;
  • 其內容寫入到iframe的主體;
  • 這個機構是空的，但有一個onload事件
  • onload onload事件定義如何注入YSlow的的JS：
    • 設置YUI_config ，所以win doc點被分析的頁面window和document分別
    • YSlow的網址，通過創建一個動態注入script到iframe的元素head

* iframe的顯示YSlow的演示的全部資產裝入

這將被分析的頁面放入一個iframe。 這個iframe將作為沙盒環境，將駐留在YSlow的。 由於沒有動態創建的iframe src屬性，將有機會獲得其母公司（被分析的頁面），因為這裡沒有發生有相同的原產地政策違反。

的YUI_config對象是很方便的，因為它設置win doc doc iframe的父（被分析的頁面），因此任何新的YUI實例將綁定默認情況下，佈線的父文檔任何呼叫到Y.all和Y.one通過Y.config.win或Y.config.doc從YUI use回調。

YSlow會的演示文稿處理iframe的window和document引用，讓YSlow的主腳本呈現的標記，以及不與父頁面的樣式發生衝突的情況下獲取這個iframe內外部CSS。 YSlow的父頁面進行掃描，以獲得後來的表現分析所需的所有組件（圖片，腳本，鏈接，背景圖片，閃光燈等）。 這是做通過，訪問Y.config.win和Y.config.doc ，因為他們是指父頁面。

跨瀏覽器抽象

YSlow的移動應該是一個書籤，在任何瀏覽器*工作。 YUI的抽象跨瀏覽器，瀏覽器的差異正常化問題，導致在一個乾淨，易於閱讀和維護代碼庫。

YSlow的不完全移植了YUI 3 -控制器層（從即將推出的應用程序組件） -但仍，所有的DOM操縱和事件處理由node和event模塊。 我們計劃在未來的版本了YUI 3到港口的YSlow的功能。

*並非所有瀏覽器目前支持

YQL的

YSlow分析，通過檢查發現在頁面上的組件的HTTP標頭頁。 HTTP響應頭是不是可以在頁面中，因此這些部件需要再次請求為YSlow的順序得到響應頭信息。 這可以通過XMLHttpRequest請求（AJAX）的組件的URL列表，但不幸的是由於同一原產地政策的限制 ，這是不可能的，除非所有組件在同一個域的頁面，這是不太可能實現。

一脈相承的政策限制的一個共同的解決方法是使用JSONP請求組件的URL列表和代理代表對YSlow的檢索HTTP響應頭，其中一個外部服務器。 由於YSlow的普及和最近的移動性能分析工作，我們期待著相當沉重的交通YSlow的移動書籤。 為了支持這樣的交通， YQL的是可伸縮的解決方案，通過一個開放的數據表命名data.headers ，檢索的響應頭和內容，為給定的URL列表，而假冒的用戶代理，以確保預期的內容是通過YSlow的檢索。

YQL的查詢組件所有YQL的查詢，而引擎蓋下的管理JSONP請求，YSlow的控制器代碼更簡單，易於維護管理工作。

未來的增強功能：新YSlow的移動界面友好

目前YSlow的移動用戶體驗是相同的桌面體驗。 一長串的性能分析數據的處理是不小智能手機屏幕上的最佳體驗。 自銳也抽象跨設備的手勢 ，YSlow的移動將獲得一個全新的移動友好的界面，在未來的版本。

性能工具的性能

YSlow的移動部署了仔細考慮其在被分析的頁面加載時間性能的影響。 YSlow的使用YUI的3模塊進行審議只包括需要加載盡可能快的YSlow的模塊。 YUI種子文件和裝載機，不包括在內，因為所有必要的模塊和子模塊組合在一起後， 瑞安Grove的性能禪宗的技巧，這使得它可以加載到一個單一的小單要求的一切：YSlow的bookmarklet.js：204KB，66KB（ GZIP），其中：

  • 銳：75KB，27KB（GZIP）
  • YSlow的：129KB，39KB（GZIP）

更多關於YSlow的

跟上YSlow的最新公佈的最新：

馬塞爾·杜蘭 作者簡介：馬塞爾·杜蘭是雅虎的卓越性能團隊的前端鉛。 他一直到網站雅虎頭版搜索隊，他於高流量的網站性能優化，並研究了網絡性能最好的做法使得網頁甚至更快。 他現在正致力於YSlow的和其他性能工具的開發，研究和傳福音。 他的目標是使網絡速度甚至超過它可以認為是沒有“只需幾毫秒的時間不會傷害”有這樣的事情。

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

分級瀏覽器支持;

7月12日，2011 8:55 PM由珍妮·唐納利和馬特·斯威尼在發展 ， 分級瀏覽器支持 | 24評論

金紫荊星章的變化

此更新的具體變化包括：

瀏覽器測試基準

Internet Explorer中 6 7 8 9
火狐 3。† 4。† 5。†
鉻† 最新的穩定
野生動物園 5。† 的iOS 3。† iOS 4的†
Webkit的 Android的2†

註釋：

  • 匕首符號（如“火狐4。†”）表示的最當前的非-β版本，分行層面獲得支持。
  • iOS或Android操作系統的設備的使用上給予任何指導。 的建議是，你選擇的設備是最具代表性的每個操作系統的用戶群。

從瀏覽器測試基準卸下年級

這GBS的更新版，代表了我們以前的更新，我們搬走直接從映射瀏覽器的經驗等級（例如“A級”和“C級”）的離境。 而不是開什麼用戶體驗是合適的瀏覽器，我們將重點放在定義一個有效的基準測試策略，測試覆蓋率最大化，最大限度地減少了測試表面。 例如，IE6的仍然顯著的全球市場份額的認股權證繼續測試，但今天的GBS IE6的用戶體驗，允許不同的是從IE9經驗。

刪除瀏覽器測試基準的作業系統

為了簡化測試，並最大限度地減少資源需求，我們不再指定操作系統應測試。 唯一的例外是當瀏覽器與操作系統的版本，在這種情況下，我們指的OS版本，而不是瀏覽器的版本（例如，“野生動物園的iOS 4”）緊密耦合。 這使我們能夠專注於瀏覽器版本的測試覆蓋率，減少跨平台redudant測試。 不同版本的同一個瀏覽器的問題是微不足道的，一般涉及到更高級別的操作系統的差異，如關鍵的處理和可用字體。 被稱為觸及問題的跨平台的代碼應盡可能多的平台上進行測試，但這種測試一般可以分離到的具體問題，而不是運行完整的回歸測試的所有功能。 你的用戶群，我們建議調整操作系統的測試優先。

為什麼是IE6名單上嗎？

IE6中仍然有足夠一個重要的全球市場份額，以保證驗證的可接受的用戶體驗。 已逐步加強戰略的一個常見的誤解，一旦瀏覽器進入“C級”，它成為“不支持”的時候，其實它的真正含義，應交付的HTML唯一的經驗。 現在我們不再規定哪個瀏覽器收到什麼樣的經驗，這是留給他們的用戶和資源為基礎的項目來決定。 的GBS集中在指定的瀏覽器需要驗證的實用經驗的基礎因素，如市場佔有率和影響力。 定義什麼是“可用”和specifiying可接受的水平退化留隊決定。 我們還推動了一個簡單的漸進增強模型，並勸阻不佔發展中的額外費用，測試，維修資源創造新的層次的項目。

GBS的預測

我們期望在未來的更新以下變化：

  • 停止在iOS 3覆蓋的Safari。
  • 添加Android上的3對Webkit的覆蓋面。
  • 新增Firefox的6覆蓋率。
  • 加入Safari的IOS 5的覆蓋面。

GBS的檔案

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

“MakeNode”部件擴展

7月8日下午02:11，在2011年由薩蒂揚| 開發 | 6評論

編者按：由於該文章最初發表中， MakeNode模塊已發布了YUI庫，並收到了一些改進。 請參閱更新的文章， 更新：“MakeNode”部件擴展 。

在我以前的文章中， 一個YUI 3應用配方 ，我表明方式使用Y.substitute一個非常基本的模板處理器。 從那裡生活的想法了，從＃YUI IRC頻道鄉親的建議，我是我的網站上提供一個Widget擴展，稱為MakeNode 。 MakeNode是不是一個通用的模板處理器，它不意味著為一體。 另一方面，它緊密集成與YUI 控件的基礎類，包括ClassName和事件傭工和國際化。 在這篇文章中，我將採取微調的例子，並修改它遵循從我以前的文章的指引和使用MakeNode。 修改後的微調組件（ JS ， CSS ， 精靈 ），以及一個例子是從我的網站。 在本文末尾可以找到更多的資源鏈接。

擴展你的組件

你一旦MakeNode加載，需要包括在你的模塊YUI().use()語句使用名稱'makenode' 然後，延長你的widget，你列出的第三個參數Y.Base.create()像這樣： 

  Y.Spinner = Y.Base.create（
      “微調”，
      Y.Widget，
      [Y.MakeNode]
      {
         / /實例成員...
      }，
      {
          / /靜態成員
      }
 ）;

您可以添加任何合適的擴展部件，如WidgetParent，WidgetChild，WidgetStdMode，沿MakeNode等MakeNode增加了兩個受保護的方法， _makeNode和_locateNodes,它會讀取從幾個靜態屬性，如果找到。

這個擴展的所有成員是protected或private，因為他們是為了組件的開發和使用這些組件的實施者，誰不應該與他們的困擾。

定義模板

你通常會做的第一件事是定義為您的組件的模板。 對於微調，我們的模板將是： 

  _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 ….}給定的方法的返回值。 後跟由空格隔開的參數的方法名稱和任何數量的加工代碼。 必須括在雙引號字符串。 數字，布爾值和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() eval eval()這樣的解析器是有限的雙反斜線但安全。什麼，但號碼， null ，布爾和雙引號字符串將被忽略。

{?}佔位符是很方便的使用複選框和單選按鈕。 它會產生字符串“checked”根據真值的處理指令的代碼如下。 因此， <input type=”checkbox” {? m getLength}/> <input type=”checkbox” {? m getLength}/>將產生顯著的複選框，如果getLength方法返回什麼，但零。 {?}將接受任何其他佔位符，但它不僅使前三感。

為{c}佔位符，我們需要定義有1 _CLASS_NAMES財產。

進一步佔位符，可以添加到MakeNode加入到他們_templateHandlers哈希。

_CLASS_NAMES財產

沿著與ATTRS和_TEMPLATE靜態屬性，我們可以定義一個_CLASS_NAMES屬性，它指向一個字符串數組。 這些字符串都將被用來生成一個類的。 因此_CLASS_NAMES: ['input']會產生的className “yui3-spinner-input” 。 那些類名存儲實例屬性this._classNames 。 {c input} “yui3-spinner-input” {c input}上面的模板中的佔位符將被替換。

你可以使用_CLASS_NAMES屬性來生成任意數量的類名，你是否在模板或不使用他們。 你仍然可以達到從內部this._classNames這些額外的類名。 使用yui3前綴NAME的靜態屬性的價值，產生的className轉為小寫，然後在給定的的字符串_CLASS_NAMES （這一次將不會變成小寫），全部由連字符分隔。 _classNames哈希也將包含為boundingBox類名和的contentBox ，下的第一個"."鍵，並根據第二個“content”鍵。 部件分配到boundingBox NAME在繼承鏈中的每個類的屬性的值派生的類名，開始yui3-widget 。 MakeNode存儲到this._classNames只有最頂級的className boundingBox 。

如果一個組件是幾個層次，從Widget一樣， SuperSpecialSpinner從的繼承SuperSpinner從繼承從繼承Spinner Widget, _CLASS_NAMES this._classNames Spinner Widget,如果其中的任何或全部定義_CLASS_NAMES屬性，MakeNode將產生所有的類名，並存儲在他們this._classNames 。 你不必包括在每個級別的名字已經宣布，在以前的水平。 事實上，它是更好的，你不會因為在每個級別的類名，使用該級別的屬性值的NAME 。 因此， SuperSpecialSpinner ， {c input}仍將導致的“yui3-spinner-input”和“yui3-superspecialspinner-input” ，所以它會保持你的CSS文件仍然有效。

{}佔位符

構件有strings配置屬性定義，雖然它不與任何值初始化。 此屬性是為了保存字符串（或通過屏幕閱讀器，閱讀）的用戶是可見的。 重要的是，你永遠不包括直接在模板中可見字符串。 這是不是的MakeNode的要求 - 在所有它從來就不是一個好主意。 應始終被視為或讀取用戶的所有字符串放置在strings屬性。 strings屬性包含了每一個人的文字是由位於其關鍵的哈希。 微調器組件有以下字符串，你可以看到在上面的模板使用。 

 字符串：{
    值：{
        輸入：“按箭頭/向下鍵輕微的增量，頁/主要增量。”
        了起來：“增量”
        下來：“減”
     }
 }，

這樣做的最好的部分是組件可以使用您的組件的開發本地化為其他語言很容易。 當創建一個微調的實例，你可以這樣做： 

  mySpinner =新的微調（{字符串：Y.Intl.get（'微調'）}）;

以這種方式設置的配置屬性strings取代與使用先前定義的語言，從語言資源文件的默認strings值。 {s}佔位訪問存儲在字符串strings屬性，無論是默認的或翻譯的，如果設置。 {s xxxx}佔位符，在事實上，沒有什麼比一個快捷方式到更多的{@ strings.xxxx}佔位符。 然而，第一次只能在頂層訪問字符串的同時，例如， {@ strings.xxxx.yyyy.zzzz}將允許您訪問字符串更深。

使用在renderUI _makeNode

我們使用模板來創建我們的組件的標記。 這樣做，我們可以調用MakeNode的_makeNode方法，是這樣的： 

  renderUI：函數（）{
     。this.get（“contentBox）追加（this._makeNode（））;
 }，

這將填補我們的部件在contentBox處理模板的標記。 _makeNode方法返回一個實例Y.Node可追加或插入任何地方，或只是為以後使用而舉行。 它不返回一個字符串，它產生一個Node實例。

_makeNode方法有兩個可選參數：一個參考模板和對象，以填補在佔位符，，作為Y.substitute 。 在我們簡單的微調例如，有一個單一模板的整體部件，但其他部件可能需要位和幾個模板件。 在這種情況下，你通常會致電_makeNode的主要部分沒有參數，調用不同的模板，再次填補多餘的部分。 例如包含此renderUI方法： 

  renderUI：函數（）{
     this._makeNode的fieldset =（）;
     this.each（函數（項目）{
         fieldset.appendChild（this._makeNode（MultipleTemplates.RADIO_TEMPLATE項））;
     }）;
    中this.get（“contentBox）追加（字段集）;
 }

_makeNode第一次調用返回一個Node實例存儲在變量中fieldset 。 樣品組件也延伸與Y.ArrayList所以RADIO_TEMPLATE將被從存儲在數組列表中的項目和所產生的附加 ​​的節點值填充fieldset前最後追加到contentBox 。 如特殊的佔位符{@} {p}仍將主要對象的屬性或屬性。 正如Y.substitute將嵌套的項目將被處理。

_locateNodes方法

MakeNode進一步提供_locateNodes方法，將盡力找到所有的元素在聲明的類名_CLASS_NAMES 。 找到特定的元素，您可以通過任意數量的className鍵，否則， _locateNodes嘗試他們所有。 對於每個發現的className的每個元素中， _locateNodes會產生一個私人的實例的屬性，使用下劃線前綴鍵的名稱和“Node”後綴。 因此，我們飛旋例如， _locateNodes會生成的屬性_inputNode ， _upNode和_downNode 。 如果有多個元素具有相同的className， _locateNodes將返回一個引用到他們的第一。 如果一個元素沒有被發現，沒有變量將被創建。

在微調組件，我們使用_locateNodes後創建的標記： 

  renderUI：函數（）{
     this.get（CBX公司）追加（this._makeNode（））;
     this._locateNodes（）;
 }，

_EVENTS的靜態屬性

一個進一步的屬性可以被定義沿線_TEMPLATE和_CLASS_NAMES ，是_EVENTS 。 _EVENTS將包含類名鍵，每個包含一個事件的類型和方法來處理它們的哈希散列。 這是更好地用一個例子來解釋： 

  _EVENTS：{
     '。'：{
        關鍵：{
             FN：“_onDirectionKey”
            參數：（Y.UA.opera“下來：”：！“記者：”）+“38，40，33，34”
         }，
        的mousedown：'_onMouseDown'
     }，
     “......”：{
        的MouseUp：'_onDocMouseUp'
     }，
    輸入：{
        變化：“_onInputChange”，
     }
 }，

_EVENTS是一個具有任意數量的屬性的對象（哈希）。 屬性的名稱，即哈希鍵，確定元素的事件，我們會聽取。 他們是在使用相同的標識符_CLASS_NAMES 。 有兩個額外的特殊功能鍵"."和".." 雖然內嵌套元素contentBox的className鍵， "."關鍵指的boundingBox本身，而".."是指包含此部件的文件。 認為他們做chdir命令時，在位於boundingBox水平。 _EVENTS財產處理後renderUI ， bindUI和syncUI方法，被稱為widget的預期，因此已經插入文檔正文內，否則".."將失敗。

條目中的每個_EVENTS是1進一步對象事件的類型作為其關鍵和1實例的方法來處理它的名稱。 _EVENTS ，是一個靜態變量，有沒有來訪問this所以它可以不採取實際功能的引用，只有名稱的事件偵聽器方法。 一些事件類型，如需要額外的參數， key事件。 在這種情況下，而不是提供的事件處理程序的名稱，你可以提供與物業fn args args對象舉行的函數的名稱和額外的參數，需要時。

MakeNode將使用Node.delegate聽嵌套元素的事件，而它會使用Y.on聽從事件boundingBox和筆體。 （注：聽任何嵌套元素的key事件僅適用於版本3.4.0pr1及以上，由於該代表團key 。事件是不是之前的所有其他功能的工作以及與以前的版本）

_EVENTS聲明是累積性的，當組件從一個繼承。 繼承鏈中的每個類都會有其自己的_EVENTS聲明分開處理。

_ATTRS_2_UI的靜態屬性

活動是雙向的，從UI組件從組件到UI。 首先是處理由_EVENTS屬性。 然後有由屬性值的變化，必須體現在用戶界面中引發的事件。 正如我在前面的文章，有任何改變配置屬性的輔助療效時提到，他們應改變事件監聽器處理，而不是可選的setter方法的屬性，它應該只處理正常化設置的值。 UI應該反映配置屬性的狀態，首先在syncUI時被初始化，然後對每一個屬性更改事件。 對於後者，我們需要附加一個事件監聽器，我們在做bindUI 。 部件已經提供了一種機制，使這個簡單，我在上一篇文章的評論。

部件使用，它包含一個與另外兩個性質，對象_UI_ATTRS SYNC和BIND實例屬性_UI_ATTRS 。 這些是一個數組，列出最初同步時的配置屬性的名稱，然後聽取以反映當前值保持UI。 部件預計每個條目有一個與之關聯的方法，由前綴屬性名後的第一個字符轉換為大寫有駱駝的情況下適當的方法名稱的屬性名稱的命名_uiSet 。 因此，如果"value" ​​在任何上市_UI_ATTRS陣列（ SYNC或BIND ）的Widget希望找到一個_uiSetValue方法。 這種方法將收到兩個參數的value設置和src的變化。 這是為我們的微調代碼_uiSetValue方法： 

  _uiSetValue：功能（價值，SRC）{
    如果（SRC ===界面）{
        返回;
     }
     this._inputNode.set（值，this.get（格式化）（值））;
 }，

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.

結論

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 .

找到的談話： bloglines technorati

共享和擴展： 書籤del.icio.us Digg它！ | reddit！

YUI and Loader changes for 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. 例如： 

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

主辦雅虎

©2006-2012雅虎公司所有權利保留。 隱私政策 - 服務條款

支持WordPress的關於雅虎 虛擬主機 。