モジュール java.desktop
パッケージ javax.swing.text

クラスView

java.lang.Object
javax.swing.text.View
すべての実装されたインタフェース:
SwingConstants
直系の既知のサブクラス:
AsyncBoxView, ComponentView, CompositeView, GlyphView, IconView, ImageView, PlainView
public abstract class View extends Object implements SwingConstants

Viewクラスは、テキスト・パッケージの非常に重要な部分です。 名前が示すとおり、テキスト・モデルのビュー、またはテキスト・モデルの一部を表します。 名前が示すように、テキスト・モデルのビュー、あるいはテキスト・モデルの一部分を表します。 このクラスはテキスト・コンポーネントの外観を扱います。

デフォルトでは、ビューは軽量です。 ビューには、ビューが状態を保持しないで多くのものを取得することができる親ビューへの参照と、モデル(Element)の一部分への参照が含まれています。 ビューは、典型的なだけで便利なマッピングである、モデルの要素を正確に表す必要はありません。 バージョン1.1および1.2の両方で機能するAPIは、移行によって生じる問題を最小化するのに便利です。 ビューがバラバラにされた場合の通常のフォーマットの結果です。 モデルが変更され、ビューがそのモデルを反映するように変更されなければならないとき、要素との実質的な関係の利便性を、ビューを生成するファクトリの構築によって簡単にしたり、ビュー各部分の追跡を継続することで簡単にします。 つまり、単純なビューはElementを直接表しますが、複雑なビューは違います。

ビューには次の機能があります。

レイアウトへの関与

組み合わされたComponentのビューには、doLayoutやsetSizeと同様のsetSizeメソッドがあります。 Componentのビューには、1つの軸と、変更が識別できることを要求する子だけを無効にできる場合を除き、invalidateと同様のpreferenceChangedメソッドがあります。

Viewはサイズを示します。最小スパン、推奨スパン、最大スパンの3つの値で表示されます。 ビューのレイアウトは各軸に依存しない方法で行われます。 View実装を正しく機能させるには、最小スパン<=推奨スパン、または推奨スパン<=最大スパンとなります。

前の文は、この図について説明しています。

レイアウトに関するメソッドの最小設定は次のとおりです。

何回も呼び出されるためにはsetSizeメソッドを作成します(サイズが変更されない場合でも呼び出されることがあります)。 setSizeメソッドは通常、最新のレイアウトを必要とする操作をView上で試みる前に、Viewのレイアウトが完了するように呼び出されます。 ビューのサイズは必ず、そのビューで指定されたスパンの最小スパンから最大スパンの範囲内の値に設定されます。 さらに、ビューで親に必要なレイアウト値に変更した場合、このビューは必ずその親のpreferenceChangedメソッドを呼出し親に引受けを要求します。 preferenceChangedが送られるまで、その親Viewは変更を認識するように要求されていません。 このため、親Viewの実装は必要に応じて子の要求をキャッシュできます。 呼出し順序は次のようになります。

親ビューと子ビューとの間のサンプル呼出し順序の例: (setSize、getMinimum、getPreferred、getMaximum、getAlignment、setSizeの順)

ビューが子供を持つ場合、正確な呼出し順序は親ビューのレイアウト機能にかかっています。 どの子に何を提供するのか、または子を1度に1つ繰返し更新するのかを指定する前に、ビューは子の推奨設定を収集することがあります。

モデルの一部を描画する

ペイント・メソッドで描画しますが、コンポーネント・ペイント・メソッドとよく似ています。 ビューは、かなり大きなツリーを生成する可能性があると考えられます。 Viewの描画に対して次のセマンティックスが用意されています。

  • ビューは、ペイント時に親からの割り当てを取得する。割当て領域が処理対象とされている領域と異なる場合、レイアウトの再実行の準備が必要。
  • 座標体系は、getContainerメソッドで返されたComponentなどの収容側Componentと同じ。 すなわち、親が明示的に座標体系を変更していない限り、子ビューは親ビューと同じ座標体系に存在する。 自分を再描画するようにスケジュールするために、ビューは収容側Componentの再描画を呼び出すことができる。
  • デフォルトは子をクリップしないことに設定。 ビューがクリッピングを本当に必要とする場合に限り、ビューをクリップ可能にするとさらに効果的。
  • 指定されたGraphicsオブジェクトはどんな方法でも初期化されない。 ビューが必要な設定をしなければならない。
  • 本来Viewは透明。 ビューがその割当て全体を描画する場合もあるが、通常は描画しない。 View実装のツリーを下位へたどってレンダリングを実行する。 各Viewはその子のレンダリングを扱う。 この動作はスレッドに対する安全性に依存している。 ビューの実装にスレッドに対する安全性を考慮する必要がない場合は、同時に使用できるほかのビューの実装が、スレッドに対する安全性を保証するツリー・トラバーサルに依存する。
  • モデルに関連するビューの順序は実装によって異なる。 子ビューは通常、モデル内で発生する順序と同じ順序で配置されるが、視覚的にまったく異なる順序で配置されることもある。 子が重複する場合、Viewの実装には重複した子に関連したZ-Orderが用意されている場合がある。

レンダリングのためのメソッドは次のとおりです。

モデルの座標体系とビューの座標体系との間の変換

ビュー・オブジェクトはファクトリから生成されており、必ずしも特定のパターンに依存することはないので、モデルの空間表現を適切に位置づける変換を実行できなければいけません。 これは次のメソッドが実行します。

変換しようとする前にレイアウトを有効にする必要があります。 この変換は有効ではないため、変更がDocumentEvent経由でモデルから送られる間は変換しないでください。

モデルからの変更に応答する

ビュー全体がいくつもの分割部分で表現されていると(ビューを変更し、最小限の新規コードの書込みをする場合、それが最適な状態ですが)、莫大な数のDocumentListenerを保持するのは不可能です。 各ビューがモデルに待機するとすれば、実際にはほとんどのビューは指定された時間に送られる変更に関われません。 モデルにはビューに関する情報がないので、変更情報の伝送をフィルタする方法がありません。 代わりに、ビュー階層自身が変更情報の送信を行います。 ビュー階層のどのレベルでも、詳細な変更情報を効率よく分配するために、ビューの子に関する情報は十分にあります。 したがって、変更はビュー階層のルートから送られます。 これは次のメソッドが実行します。