実践 カスタマイズ (3) ビューカスタマイズ

ビューに関して記述する。

ビューとは原則データを抽出する参照用の一覧画面である。

ビューの種類は以下の5種類存在する。配置場所の違いが種類の違いである。

・共有ビュー
トップ画面(※)に配置されるビュー。

※ログイン後リボンからクリックして表示される下記のようなビュー

20140829_001

・関連ビュー

フォーム上に表示される関連しているエンティティのビュー。

下記は取引先企業のフォーム。右列に表示されているのは、取引先担当者関連ビュー。

20140829_002

・簡易検索ビュー

簡易検索を実行した結果のビュー。

簡易検索後に表示されるのはこのビューという点に注意。

また、どの列を検索対象とするかを決定するための設定がこのビューのカスタマイズにのみ存在している。

検索対象は該当ビューのみ。一意に関連するエンティティの列でも検索対象に含むことはできない。

20140829_003

・高度な検索ビュー

高度な検索を実行した後に表示されるビュー。

余談であるが、2011のあるURバージョンでは一意に関連するエンティティの列を表示すると

クラッシュするという不具合が発生した。

20140829_004

・検索ダイアログボックスビュー

Lookupボタンクリック後の選択画面上のビュー。

このビューの最左列はエンティティのプライマリーフィールドにしなくてはならない。

20140829_005

以上、それぞれの種類と特徴である。

次に私が考える設計上のポイントを記載する。

■ビューの列数はスクロールなく表示できる分までにするよう事前に合意する

表示可能な列数に上限はほぼないと思われる(少なくとも100フィールドは配置可能)。

逆にいうと、「面倒なので全部配置して」もしくはこれに順ずる要求をされることは意外と多い。

システム開発一般に言えることだが、作るものが多くても作ることはそれほど苦にならない。

しかしながら、これに変更が加わり、さらには設計書も修正するということになると作業量は

大きく変わってくる。作業はノンコーディングであるため容易であるが、

思った以上の工数に膨らむことがある。

■設けるビューの数に上限を設けるよう事前に合意する

上記と同じ観点であり、目安は10個前後だと考える。

複数部署が利用するエンティティの場合、各要望をとにかく取りいれて20個も30個も設計するケースがある。

大半はほとんど使われないものであったり、特定業務でのみ利用したりするものであることが多い。

この場合は、個人ビューで作成してもらうような方法を提案するべきである。

■すべてのビューの列配置は同じとするよう事前に合意する

これも工数の観点である。特に変更管理が始まると面倒であることは上の2つと同様である。

■検索されるレコードは業務上最小限となるように条件を設計する。複雑な条件は避ける。

これはパフォーマンスの観点からである。1つの指針としては「すべての○○」のようなビューは避けるか

既定のビュー(初期表示時のビュー)にしないことである。

また、関連するエンティティのフィールド表示を何でもかんでもするのはよろしくない。

様々な条件に依存するが、感覚値としては数千件~数万件以上のデータが存在するエンティティでは

考慮をしたほうが望ましいと思われる。

以上。ビューに関してはそれほど複雑な設定をする必要がないため、顧客もそれなりに機能を理解する。

理解できるものに関しては比較的多くの要求や確認を求めてくるものである。

最初は実施してもよいと判断したものが思いのほか大きなものになる。

こういうことに注意すべきだと思う。

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中