ヤフーユーザーインターフェイスブログ（YUIBlog）

YUIシアター-ジェフ·クレイグ： "ローダーの神秘を解く：高度なモジュールの構成"（31分）

YUIConf 2011年から本講演では、 MeeboのエンジニアとYUI寄稿ジェフクレイグは（ @ foxxtrot ）あなたはいつもYUI Loaderの詳細を知りたいと思ったけど聞いて恐れていただすべてを明らかにする。 これはYUI 3で、パフォーマンス·クリティカルな仕事をしている人には必見です。

リンク

• YouTubeのHDで表示
• スライド
• YouTubeでフルYUIConf 2011年リスト

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

YUI：営業時間木12月15日

YUI 3.5.0 PR1

YUI 3.5.0 PR1が利用可能になりました ！ これは3.5.0の3つのプレビューリリースの最初のものです。

この営業時間のために我々は、PR1に何があるかを強調表示し、 あなたが 3.5.0は岩の固体であることを確認するために関与できるかについて議論されるでしょう。 また、すでに3.5.0 PR1を（これは使い始めました素晴らしい開発者からのショーの、手を求めることでしょうCDN上で ）。 木曜日来る、:)の下に手でキャッチされない

また、 YUIライブラリのステージングサイトは、最新のユーザガイド、APIドキュメントで更新されており、からのフィードバックに応じて最後の営業時間 、我々は今、私たちの使ってGitHubのwikiを追跡するために継続的な開発の議論を 。

記録

録音はYUILibrary YouTubeチャンネル上で利用できる 。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

YUI 3.5.0のAppフレームワークの変更

の最初のリリース以来、 アプリケーションフレームワーク YUI 3.4.0で、我々は、それが採用されているどのように迅速に驚いていました。 プロジェクトでは大と小 、長い時間YUIの両方のユーザーとライブラリへの完全に新しいている人は熱狂的にアプリFrameworkのMVCコンポーネントを使用して、偉大なフィードバックやバグレポートを提供してきました。 ありがとうございました！

YUI 3.5.0では、アプリケーションフレームワークでは、バグ修正といくつかの主要な強化機能の多くを受け取ることになります。 エリックFerraiuoloは彼の今後の変化の多くカバー素晴らしいYUIConfの話を 、私たちはあなたが来るの知っていると何を3.4.xのからApp Frameworkベースのコードをアップグレードする予定がある場合はあなたが準備する必要がありますので、同様にそれらをここに強調したい3.5.0へ。 これらの変更は、内に既にあるYUI 3.5.0 PR1今日リリースされましたので、今はそれらのテストを開始するのに最適な時間です。

Y.ControllerはY.Routerです。

"コントローラ"は実際に特に多くの伝統的なコントローラーのような役割Y.Viewを果たしていることが与えられたURLベースのルーティングでは、より多くの自分自身に関係するコンポーネントの愚かなと紛らわしい名前だった。 私たちは弾丸をかむと3.5.0でY.RouterにY.Controllerクラスの名前を変更することに決めました。 Y.Controllerは、下位互換性を維持するためにエイリアスになりますが、このエイリアスは、最終的に削除されますので、新しい名前を参照するようにコードを更新する必要があります。

新しいルートハンドラのシグネチャ

Y.Routerのルートハンドラ関数用のメソッドのシグネチャは、することが多くの類似したように若干変更された表現とサーバ（我々は現在3.5.0のために取り組んでいる機能）で使用する場合、ルータのAPIがより自然にする。

：以前は、ルートハンドラ関数は、2つの引数を受け取ったreq （要求オブジェクト）とnext （関数）。 ：3.5.0には、ルートハンドラは、三つの引数受け取りますreq 、 res （レスポンスオブジェクト）を入力し、[ next 。

後方互換性のために、新しいres引数もまったく同じように動作し関数でnext期待しているので、古いスタイルのルートハンドラnext第二引数は3.5.0で正常に動作し続けますように。 しかし、この互換性のシムは、最終的に削除されますので、あなたのコードを更新する時間をおきすぎていません。

いくつかのプロパティは、現在の属性です。

プロパティが恩恵を受けないので、我々は、3.4.0でアプリケーションフレームワークコンポーネントの設定可能なオプションのプロパティを使用することのない、完全に、YUIのようなスタイルで実験したが、これは制限する少しより少し混乱し、多くのことが判明した変更イベント、setter、および操作属性のようなバリデータから。 したがって、3.5.0で、我々は属性にこれらのプロパティの多くを変換する。

残念ながら、この変更は後方互換ではありません、Y.Controller（現在Y.Router）またはY.Viewを使用するように既存のコードを更新する必要があります。 具体的には、Y.Routerのhtml5 、 root 、およびroutesプロパティは、現在の属性であり、Y.Viewのcontainer 、 model 、およびmodelListプロパティは、同様に現在の属性です。

これに加えて、Y.Viewのcontainer属性は、ページ上のノードを見つけるために使用されるCSSのセレクタとして文字列値を扱います。 3.4.xのには、ノードに変換されるべき生のHTMLを表す文字列値を仮定した。 古い振る舞いを得るために、ちょうどから、既存のHTML文字列の値を変更'<div>foo</div>'するY.Node.create('<div>foo</div>') 。

3.5.0 PR1のマニュアルを参照

YUI 3.5.0 PR1は、これらの変更およびその他の変更のために作業中のドキュメントは、私たちで見つけることができますステージングのウェブサイト 。 ここでアプリケーションフレームワーク3.5.0で非推奨とあなたのコードをアップグレードする方法についての詳細に関する情報を含む、関連するステージングドキュメントへのリンクは、次のとおりです。

• ルーター
• ビュー

stage.yuilibrary.comのコンテンツは、進行中の進行中の作業を反映しており、不完全な、あるいは時折我々のテストの新しいもののように壊れた可能性があることに注意してください。 あなたは常に我々の生産現場での最新の安定版リリースのためにドキュメントを見つけることができますyuilibrary.com 。

新しい他とは何ですか？

このブログ投稿で、私は3.5.0でアプリケーションフレームワークに来て重要な非推奨をまとめましたが、機能拡張の多くとボンネットのバグ修正もあります。 3.5.0 PR1のApp Frameworkの変更点の完全なリストについては、 HISTORYファイルを参照してください 。

また、Y.App、あなたを得るでしょう、単一の使いやすいAPIにURLベースのルーティングとビューの管理をラップアプリケーションフレームワークの驚くばかりの新しい高レベルのコンポーネントについて、すぐにエリックからのブログ投稿を探してゼロから時間がないの動作中のアプリケーションに。

我々はあなたがプレビューリリースの思い過ごし、私たちはあなたから聞いてみたい！ あなたに私達にフィードバックを送ることができるフォーラムに、 バグレポート 、 Twitterで Freenodeの＃ゆいIRCチャネル上で、または単にコメントではここでチャイム。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

YUI 3.5.0 PR1は、利用可能になりました

YUI 3.5.0のプレビューリリース1は、開発者コミュニティからのテストとフィードバックのために配備されています。 あなたのYahoo! CDN上でそれを見つけることができますyui.yahooapis.com/3.5.0pr1/build/yui/yui-min.js 、またはzipファイルをダウンロードしてあなた自身でそれをホストする予定がある場合。

PR1で導入された変更のロールアップには、私たちのGitHubのWikiで入手できます。 さらに、確認することができますこのリリースで解決されたチケットのリストを 。

作業中のユーザガイドおよびAPIドキュメント 3.5.0のためには、私たちのステージングサイトで見つかったが、私たちは新しいものをテストする場所であるので、これらのドキュメントは、不完全な、あるいは壊れた可能性があること注意することができます。 最新の安定版リリースの公式ドキュメントは、常に私たちの生産現場、で見つけることができますyuilibrary.com 。

多くの変更がYUI 3.5.0の今後のプレビューリリースで導入されます。それらのいくつかは開発者自身の枝で現在、以下のプル要求を介して初期レビューのために利用できます。

• 新しいDataTableのアーキテクチャと実装
• 新しいButtonモジュール

このリリースに対するバグを提出するために、我々をご覧ください。 バグ追跡システムを 。 あなたはこれらのおよび将来のモジュールに入力を提供したい場合は、3.5.0のリリースに関連する様々なトピックについて継続的な議論は、私たちに起こっているGitHubのウィキ。

すべて計画通りに進めば、我々は2012年1月30日にYUI 3.5.0 PR2を解放したいと思っています。 幸せな休日！

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

YUIシアター-アレンラビノビチ： "YUIカレンダー-スタイルとモジュールの構築のケーススタディ"（47分）

YUIConf 2011年から本講演では、YUIのエンジニアアレンラビノビチ（ @ allenr ）株式彼は建築家と新しいビルドに使用されるプロセスのカレンダーウィジェットを、 YUI 3、あなたが独自のウィジェットを構築するために同様のプロセスを使用する方法について説明します。 彼はまた、新しいコンポーネントをオフに示しており、複数のカレンダーのレンダリングをスピードアップするために使用される巧妙なパフォーマンスのトリックを明らかにする。

リンク

• YouTubeのHDで表示
• YouTubeでフルYUIConf 2011年リスト

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

YUIシアター-パットCavit： "自動ウェブサイトの最適化"（32分）

パットCavit（ @ tivac ）でのフロントエンドエンジニアArenaNetとアクティブなYUIの貢献者とコミュニティメンバーは、そのようなファイルの連結、縮小、名前の変更や、その他の使用など、ビルド時のウェブサイトの最適化を自動化することでこの話を与えるためにYUIConf 2011で私達に参加しましたAntはビルドツール。

リンク

• YouTubeのHDで表示
• YouTubeでフルYUIConf 2011年リスト

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！

バルクエディタ·ウィジェット：YUI 3ギャラリーで

簡易プラグインのためにYUI 3 DataTableには、それが簡単に不可能な操作として、レコードのページ全体を編集することができます。 しかし、時にはあなたは、さらに操作を行う必要があります。 たとえば、同時にあなたが快適に単一ページに収まりきらない複数のレコードを編集する必要があります。 または、追加複製、原子操作の一環として、レコードの削除をサポートする必要があります。 または単一の表のセルに配置することにより、視覚的にグループフィールドにたいと思うかもしれません。 バルクエディタのウィジェットは、これらすべての可能性をサポートしています。

（ この例で再生するスクリーンショットをクリックします 。）

概要

バルクエディタ·ウィジェットは3つのコンポーネントから構成されています。

Data source

挿入、削除、および変更された値：これは、YUIのDataSourceおよび変更を管理してラップします。

Base widget

これは、各レコード内のレコードとフィールドを管理することで、編集するための基本的な構造を提供します。 派生クラスではdiv、tbody要素、または他のコンテナかもしれない別々の行 、に各レコードをレンダリングする責任があります。

HTML table implementation

これは、HTMLテーブルのtbody要素には、各レコードをレンダリングするためにベースのウィジェットを拡張します。 列の構成は、表の各列に表示されるフィールドを決定します。 カスタムセルのフォーマッタは、単一の表のセルに複数のフィールドをレンダリングするために使用することができます。

設定

上記のスクリーンショットを生成例では、コンフィギュレーションができるだけ簡単にされています。

fields各レコードの編集可能な値を定義します。 デフォルトのタイプは入力です。 他の有効な型は 、select と textareaがあります。 （ 選択は、値のリストを必要とします）基本的な検証によって提供されているForm Managerのギャラリーモジュール。 これはカバー必須フィールド、長さの制限、および数値の範囲を 。 より複雑な検証を指定することにより行うことができますregex 、または独自の関数（ fn ）。 ここに住んでいる例からの抜粋は、次のとおりです。

 VARフィールド=
 {
	タイトル：
	 {
		タイプ： 'テキストエリア'
	 }
	年：
	 {
		検証：
		 {
			 CSS： "yiv整数：[1500,2100] '
		 }
	 }
	カラー：
	 {
		タイプ： 'SELECT'、
		値：
		 [
			 {値： "赤"、テキスト： 'レッド'}、
			 {値： 'グリーン'は、テキスト： 'グリーン'}、
			 {値： 'ブルー'、テキスト： 'ブルー'}
		 ]
	 }
 };

Y.BulkEditDataSourceインスタンスが必要ですY.DataSource 、次のパラメータを：

uniqueIdKey

各レコードを一意に識別するキーの名前です。

generateRequest

のためにリクエストパラメータを生成する機能Y.DataSource 。 （ので、これは例では空になってY.DataSource.Local常にすべてのデータを返します。）

extractTotalRecords

からレコードの合計数を抽出する機能Y.DataSource応答。

の例では、使用しているのでY.DataSource.Local 、 totalRecordsReturnExprまた必要となります。 応答内のレコードの総数を格納する場所をこのOGNL式を指定します。 （ことに注意してくださいextractTotalRecords 、この値を読み込みます）。

 VAR DS = newはY.BulkEditDataSource（
 {
	 DS：raw_ds、
	 uniqueIdKey： 'id'を、
	 generateRequest：関数（）{}、
	 totalRecordsReturnExpr： 'meta.totalRecords。'
	 extractTotalRecords：関数（レスポンス）
	 {
		 response.meta.totalRecordsを返します。
	 }
 }）;

Y.HTMLTableBulkEditorデータソース、フィールドの設定、および列の設定が必要になります。 カスタムフォーマッタを指定しない限り、列の設定では、キーは、フィールド名です。 ラベルは列のタイトルとして使用されます。 ここに住んでいる例からの抜粋は、次のとおりです。

 VARのカラム=
 [
	 {
		キー： 'チェックボックス'、
		ラベル： '<input type="checkbox" id="select-all" />'、
		フォーマッタ：関数（O）
		 {
			 VARマーク= '<input type="checkbox" class="record-select" id="{id}" />';
			 o.cell.set（ 'innerHTMLプロパティ'、Y.Lang.sub（マークアップ、
			 {
				 ID：this.getRecordId（o.record）
			 }））;
		 }
	 }
	 {キー： 'タイトル'、ラベル： 'タイトル'}、
	 {キー： '年'、ラベル： '年'}、
	 {キー： '色'、ラベル： '色'}
 ];

（ライブの例では、マイナーな拡張子に定義されていることに注意してくださいY.HTMLTableBulkEditorチェックボックスの列を処理するためです。）

またのインスタンスを渡すことができますY.PaginatorするY.BulkEditDataSource 。 これは別の、より複雑で実証されている実際の例 。

ローカルとリモートのデータソース

ローカルまたはリモートデータソースを使用するかどうかを決定するときは、慎重にトレードオフを考慮する必要があります。 トレードオフは明白なのは、改ページ位置を自動修正する場合は、DataSourceローカルが高速であるということですが、最初のページのロードに時間がかかるでしょう、そして、それはクライアント上でより多くのメモリを必要とします。

バルクエディタ·ウィジェットは、しかし、追加のトレードオフを課している。

まず、YUI DataSourceは、不変のデータを返す必要があります。 これは、ローカルのデータソースの自動ですが、リモートデータソースに実装するのが難しいことができます。 あなたは、複数のユーザーがそれらを変更することが許可されている一括編集操作の間、データベーステーブル内の行をロックする必要があります。

第二に、ローカルとリモートのデータソースとの間の選択は、あなたがデータを保存するために許可されている方法に影響を与えます。 あなたは、ローカルデータソースを使用するときは、サーバーへのすべての有効なレコードを保存する、すなわち、 ベストエフォート型の保存を行うことができますが、データソースをローカルからそれらを削除し、ユーザーが無効な値を持つレコードに集中することができます。 すべてのデータが有効である後に、リモート·データ·ソースを使用する場合は、不変性の要件は、あなただけがすべてか無か節約を行うことができ、すなわち、データは保存することができます。

実世界のユースケース

バルクエディタ·ウィジェットのオリジナルの動機は、アップロードされたスプレッドシートの後処理を実行できるようになりました。 後処理のステップを導入するスプレッドシートの値は完璧なものにするために必要がなくなります。 エラーではなく、全体のアップロードを拒否するのバルクエディタウィジェットにフラグを付け、固定することができます。 さらに、サーバー上の処理は各レコードに必要な追加の値の最良の推測の割り​​当てを行うことができ、ユーザーが保存する前にこれらの余分な値をチェックし、修正することができます。 これは、スプレッドシートの初期作成を簡素化します。

このシナリオでは、リモート·データ·ソースが最適です。 アップロードされたデータは、スクラッチ領域に格納され、他のユーザがそれを見ることができませんので、したがって、不変が保証されています。 "オール·オア·ナッシング"は保存が適切である：すべてのエラーが修正されました、保存操作は標準的なアップロード操作のように、アトミックです。

についての著者： ジョンLindalは （ @ jafl5272 Twitter上）の上に土台を構築、リードエンジニアの一つであるYahoo!を APTは、構築されています。 以前に、彼はヤフーパブリッシャーネットワークに取り組みました。

会話を検索： Bloglinesの | テクノラティ

共有および拡張： del.icio.usでブックマーク | Diggそれ！ | reddit！