Ext2.0のレイアウト

昨日あれこれ不毛なTrial-and-errotをやっていたこともあり、ドキュメントを訳すことの重要性を非常に強く再認識したので、レイアウトについても訳してみる。

元ネタ：
http://extjs.com/learn/Ext_2_Overview#Layouts
Layoutsの項目

超脱線：　Trial and error （トライアル＆エラー）

とその前に、Trial and errorと書いたところで、頭の中に浮かんだイライラ感をココで吐き出してみる。

トライ＆エラーっていうのやめれ；；

結構日本人で教養のあると思われるひとまでトライ＆エラーっていうのが最近目立つ。

トライアルの"アル"にアクセントがないから、次に来るこれまたアクセントのない"アンド"と一緒にごにょごにょっとなりやすいため、Trial&Errorという言葉を知らなかった人が、「トライ＆エラーにちがいない」とか思って見よう見まねで使い出し、それが周囲に伝染していったんだろうなぁとおもうけど。

まあ、"トライ"も"エラー"もこのようにカタカナで書いて通じるわけで、外来起源の日本語だと捉えたら"トライ・アンド・エラー"も日本語としては間違いでないという解釈も成り立ちうるかもしれない。が、やはりそんな変な言葉使うぐらいなら「試行錯誤」っていう伝統的で立派な日本語使おうよって思う。

まあでもカタカナを使ってインパクトを出したいならしょうがない。そうだな・・「トライとエラー」とかいったらいいんじゃないか？それはそれで確信犯的でかっこいいかもしれないからさ。（ｗここは意見が分かれるだろうけどｗ）

トライ＆エラーがダメぽなのは、英語として捉えたとき、これは慣用句だからっていうこともできるけど、原理的にはTryは動詞であってErrorは名詞。そもそも動詞と名詞を並列で並べるのはぜんぜんダメポということです。昔勉強したところによると英語はparallelismっていうのが凄く大事な言語だそうで、and の左右に来るものの型が違ったらエラーになるっすよ。英語はプログラミング言語でいうとところの型付けがはっきりしたJavaやＣ言語みたいなイメージ？

Javaで "hoge" + 3　は　"hoge3"にはならず　エラーなのと一緒。

Parallelism違反の別例として、よく中小企業の企業理念とかで、えらそーに社長が英単語並べてるときに痛いってことが挙げられる。
例えばStandard, Strategy, Speed なんていうのは名詞が並んでて３Ｓとかいってみたらカッコいいのかもしれないけど、そこにSucceedとかつけて４Ｓとかしちゃダメポよ。Succeedは動詞なんだから。つけるならSuccessでね。まあ、Successは概念的にそもそも並列にしちゃおかしい訳で、この場合に限っては確信犯的に＆we Succeedなんてふうに並べるならかえっていいかも知れんけど・・　って何の話だっけ。　話を戻そう。

昨日Extで不毛な試行錯誤してたら、今日いい文章みつけたから訳しますってことだったね。

Introduction

最初の2段落は1.1からくらべてすげーよくなったとか、全部ＥＸＴがやってくれるから、あなたは簡単よだとか、そういうことが書いてあるだけなので略。

次からが重要そう

Layouts are not intended to be created directly via the new keyword. Instead, they are created and used internally by the container classes. Containers themselves know nothing about layout — they simply delegate layout duties to whichever layout class has been specified during their configuration. Anytime you create a container, you can specify its layout style and configure any options that are specific to the layout class via the layoutConfig property. For example:

Layoutはnew キーワードで直接作るように意図されたものではない。そうではなく、これら（色々なレイアウト含めすべてのレイアウトは）Containerクラスによって内部的に生成され使われる。（サブクラス含めすべての）Containerはそれ自身レイアウトのことは何も知らない。Containerは単に、どのクラスでもよいのだが設定時に特定されたレイアウトクラスにレイアウトの仕事を移譲する。Containerをつくるときはどんなときでも、そのレイアウトスタイルを決めることができ、またその対応するレイアウトクラスに設定できるオプションをlayoutConfig属性を通じて設定できる。例えば：

var panel = new Panel({
    title: 'My Accordion',
    layout: 'accordion',  // The layout style to use in this panel
    layoutConfig: {
        animate: true     // Layout-specific config values go here
    }
    // additional Panel options...
});

It is also important to understand that when you create nested layouts, with Panels containing other Panels, every Panel in the layout must have a layout specified. In most cases when you don't need a specific layout style like 'border' or 'accordion,' you will probably want to specify 'fit' as it will still manage the base sizing of the Panel for you within its container. If you do not specify a layout, the default ContainerLayout class will take over so that the application will still work. However, in most real world cases, the resulting behavior will not be what is expected without an explicit layout.

Each layout class supports its own specific config options. Be sure to reference the API docs for each layout for more information.

またこれを理解しておくことも重要だ。ネストしたレイアウトをつくるとき、パネルが他のPanelを包含していたとしたら、そのレイアウトの中の全てのPanelにレイアウトを指定しておく必要がある。'border'や'accordion'のような特別なレイアウトを必要としないようなときは、ほとんどの場合たぶん'fit'を指定すればいいだろう。なぜなら、'fit'でもPanelとしての基本的なサイズ調整管理をコンテナとの間でしてくれるからだ。もしレイアウトを指定しないと、それでもアプリケーションが動くようデフォルトのContainerLayoutクラスが設定される。しかし、実際のほとんどのケースでは、明示的なレイアウトなしでは結果としての振る舞いは期待したものと異なるもとのなってしまうだろう。

各種レイアウトクラスは、それぞれそれ自身に特化した設定オプションをサポートしている。詳しくはAPI docsを参照されたし。

ContainerLayout

This is the base class for all other layout managers, and the default layout for containers when a specific layout is not defined. ContainerLayout has no visual representation — it simply manages contained items, rendering them when needed and handling basic duties like resize buffering. ContainerLayout should not generally be created directly, although it can be extended to create custom layouts.

他の全てのレイアウトマネージャの基底クラスで、特にレイアウトが定義されなかったときのcontainerオブジェクトのデフォルトレイアウトとなるものです。ContainerLayoutは視覚表現をまったく持ちません。即ち単に包含されたitem群を管理し、必要に応じてそれらを描画したりリサイズバッファリングなどの基本的な作業をこなすだけです。ContainerLayoutは一般的には直接作成されるべきものではありませんが、カスタムのレイアウトを作成する場合はこのクラスを拡張して使うこともできます。

CardLayout

CardLayout is a specific layout used in cases where a container holds multiple elements, but only a single item can be visible at any given time. Most commonly, this layout style is used for wizards, custom tab implementations, or any other use case requiring multiple, mutually-exclusive pages of information.

CardLayoutは、あるコンテナが複数の要素を保持しているものの、常にただひとつだけの要素が見えるような場合に使うためのレイアウトです。よく使われるケースとしては、ウィザードやカスタムでのタブの実装、ないし複数の相互排他的なページから成る情報表示が必要なケースが挙げられます。

AbsoluteLayout

This is a very simple layout that allows you to position contained items precisely via X/Y coordinates relative to the container.

コンテナからの相対X/Y座標を通じて、包含された部品群を正確に配置することができるとてもシンプルなレイアウトです。

ColumnLayout

This is the layout style of choice for creating structural layouts in a multi-column format where the width of each column can be specified as a percentage or pixel width, but the height is allowed to vary based on content.

マルチカラムフォーマットで構造的なレイアウトを作成するための選択肢となるフォーマットです。即ち、それぞれの列の幅がパーセントまたはピクセル単位で指定できる一方、高さは内容に応じて変化することが許されます。

AccordionLayout

The AccordionLayout contains a set of vertically-stacked panels that can be expanded and collapsed to display content. Only one panel can be open at a time.

AccordionLayoutは、内容表示のために開いたり閉じたりするパネルを垂直に積み上げたセットを包含します。一度に開くことができるパネルはただひとつです。

FitLayout

This is a simple layout style that fits a single contained item to the exact dimensions of the container. This is usually the best default layout to use within containers when no other specific layout style is called for.

単一の部品を、コンテナの大きさにぴったり正確にフィットさせるシンプルなレイアウトスタイルです。他に特に必要なレイアウトスタイルがない場合、FitLayoutはたいていコンテナの中で使うのにデフォルトとしてもっとも適したレイアウトです。

AnchorLayout

This layout is for anchoring elements relative to the sides of the container. The elements can be anchored by percentage or by offsets from the edges, and it also supports a virtual layout canvas that can have different dimensions than the physical container.

このレイアウトはコンテナの両側の縁（へり）から相対的に要素をアンカーするためのものです。アンカーする要素はパーセント比率か両縁からのオフセット値でアンカーすることができます。また実際のコンテナとは異なるサイズの仮想的なレイアウトキャンバスも
実現することができます。

FormLayout

The FormLayout is a utility layout specifically designed for creating data entry forms. Note that, in general, you will likely want to use a FormPanel rather than a regular Panel with layout:'form' since FormPanels also provide automatic form submission handling. FormPanels must use layout:'form' (this cannot be changed), so forms needing additional layout styles should use nested Panels to provide them.

FormLayout は、特にデータ入力フォームを作るために設計されたユーティリティレイアウトです。特に注意すべきなのは、一般的には、普通のPanelに layout:'form'と指定したものよりは、おそらくFormPanelを使うのがよいということです。なぜなら、FormPanelであれば自動的にフォーム提出を扱う部分も提供するためです。FormPanelはlayout:'form'を使わなくてはならず（これは変更不可能です）追加的なレイアウトスタイルが必要なフォームをつくるときは、ネストしたPanelを用いる必要があります。

BorderLayout

This is the exact same layout style as BorderLayout in 1.x — layout regions with built-in support for nesting, sliding panels open and closed and splitters separating regions. This is the most common layout style for the primary UI in typical business applications.

これは、1.xでのBorderLayoutとまったく同じもので、レイアウト領域はネストやパネルのスライド（開いているものも閉じているものも）、それに、領域を隔離するスプリッタ
をビルトインでサポートします。典型的なビジネスアプリでの主要なＵＩを担う最も広く使われるレイアウトスタイルです。

TableLayout

This layout style generates standard HTML table markup with support for column and row spanning.

このレイアウトスタイルは列と行をまたがることができる標準のＨＴＭＬテーブル表記を生成します。