第5章：最後に、いくつかのUIで遊べるもの¶

新しい model と、対応する access rights を作成しましたので、ユーザーインターフェイスとやり取りする時間です。

この章の終わりには、デフォルトのリストとフォームビューにアクセスするためのいくつかのメニューが作成されています。

データファイル(XML)¶

参考: このトピックに関連するドキュメントは、データファイルにあります。

In 第4章：セキュリティー－簡単な紹介, we added data through a CSV file. The CSV format is convenient when the data to load has a simple format. When the format is more complex (e.g. load the structure of a view or an email template), we use the XML format. For example, this help field contains HTML tags. While it would be possible to load such data through a CSV file, it is more convenient to use an XML file.

XMLファイルは、CSVファイルと同じフォルダに追加し、 __manifest__.py で同様に定義する必要があります。データファイルの内容は、モジュールのインストールやアップデートの際に順次読み込まれるため、CSVファイルに関する注意点はXMLファイルにも当てはまります。データがビューにリンクされている場合は、 views フォルダに追加します。

この章では、XMLファイルを介して最初のアクションとメニューをロードします。アクションとメニューはデータベースの標準レコードです。

注釈

パフォーマンスが重要な場合、XML形式よりもCSV形式の方が好まれます。これはOdooの場合で、CSVファイルの読み込みはXMLファイルの読み込みよりも高速です。

Odooでは、ユーザーインターフェース(アクション、メニュー、ビュー) の大部分は、XMLファイルで定義されたレコードを作成、結合することで定義されます。よくあるパターンは、メニュー＞アクション＞ビューです。レコードにアクセスするには、ユーザーはいくつかのメニューレベルをナビゲーションします。最も深いレベルは、レコードのリストを開くトリガーとなるアクションです。

アクション¶

参照: このトピックに関連するドキュメントは、アクションにあります。

注釈

目標: このセクションの終わりには、アクションがシステムに読み込まれているようになっているはずです。UIにはまだ何も表示されませんが、ファイルがログに読み込まれているはずです。

INFO rd-demo odoo.modules.loading: loading estate/views/estate_property_views.xml

アクションは3つの方法で起動することができます。

メニューアイテムをクリックすることで（特定のアクションにリンク）
ビュー内のボタンをクリックすることで（アクションに接続されている場合）
オブジェクトに対するコンテキストアクションとして

この章の最初のケースのみを取り上げます。 2つ目のケースは、 later chapter <09_actions>`で、最後のトピックが高度なトピックに焦点を当てます。不動産の例では、メニューを「不動産」にリンクしたいと思います。 roperty` モデルでは、新しいレコードを作成できます。アクションは、メニューとモデルの間のリンクとして見ることができます。

test_model の基本的なアクションは次のとおりです。

<record id="test_model_action" model="ir.actions.act_window">
    <field name="name">Test action</field>
    <field name="res_model">test_model</field>
    <field name="view_mode">list,form</field>
</record>

idは、外部識別子（ external identifier ）です。これは、(データベース内の識別子を知らなくても) レコードを参照するために使用できます。
model は ir.actions.actions_window (ウィンドウアクション (ir.actions.actions_window)) の固定値を持ちます。
name はアクションの名前です。
res_model はアクションが適用されるモデルです。
view_mode は利用可能なビューです。この場合はリストとフォームビューです。他のビューモードがあることを、 :doc:`later <14_qwebintro>`が表示されます。

Odooにはいくつかの例がありますが、これはシンプルなアクションの良い例です。次の演習ではXMLデータファイルが必要になるので、その構造に注意してください。

Exercise

アクションを追加してみましょう。

適切なフォルダに estate_property_views.xml ファイルを作成し、__manifest__.py ファイルで定義します。

モデル estate.property のアクションを作成します。

サーバーを再起動すると、ログにロードされたファイルが表示されます。

メニュー¶

参考: このトピックに関連する文書は、ショートカットにあります。

注釈

目標: このセクションの終わりには、3つのメニューが作成され、デフォルトのビューが表示されているはずです。

メニュー (ir.ui.menu) の宣言と対応するアクションへの接続の複雑さを軽減するために、 <menuitem> というショートカットを使うことができます。

test_model_action の基本メニューは次のとおりです。

<menuitem id="test_model_menu_action" action="test_model_action"/>

メニューの test_model_menu_action はアクション test_model_action にリンクされ、アクションは test_model モデルにリンクされます。前述したように、アクションはメニューとモデルの間のリンクとして見ることができます。

ただし、メニューは常にアーキテクチャに従っており、実際には3つのレベルのメニューがあります。

アプリスイッチャーに表示されるルートメニュー (Odoo Communityのアプリスイッチャーはドロップダウンメニュー)
トップバーに表示される第1レベルのメニュー
アクションメニュー

構造を定義する最も簡単な方法は、XMLファイル内に追加することです。 test_model_action の基本的な構造は次の通りです。

<menuitem id="test_menu_root" name="Test">
    <menuitem id="test_first_level_menu" name="First Level">
        <menuitem id="test_model_menu_action" action="test_model_action"/>
    </menuitem>
</menuitem>

3つ目のメニューの名前は、 action の名前から取っています。

Exercise

メニューを追加してみましょう。

estate_menus.xml ファイルを適切なフォルダに作成し、 __manifest__.py ファイルで定義してください。データファイルの読み込み順序のことを忘れないでください。 ;-)

前の演習で作成した estate.property アクション用に、3レベルのメニューを作成します。期待される結果については、このセクションの目標を参照してください。

サーバーを再起動し、 ブラウザを更新1 します。これでメニューが表示され、最初の不動産物件広告を作成することができるはずです。

フィールド、属性、ビュー¶

注釈

目標: このセクションの最後に、販売価格は読み取り専用とし、ベッドルーム数と入居可能日はデフォルト値となるようにします。さらに、レコードが複製されても、販売価格と入居可能日の値はコピーされないようにします。

予約済みのフィールド active と state が estate.property モデルに追加された状態になります。

これまでは不動産物件広告に汎用ビューを使用してきましたが、ほとんどの場合、ビューを微調整すると思います。Odooでは様々な微調整ができますが、通常、最初のステップとして次のことを確認します。

特定のフィールドにデフォルト値を設定する
特定のフィールドは読み取り専用
レコードを複製する際にコピーされないフィールドがある

この不動産ビジネスのケースでは、次のようにしたいと考えています。

販売価格は読み取り専用とします (後で自動的に入力されます)
レコードを複製する際、入居可能日（availability date）と販売価格（selling price）はコピーされないようにする。
ベッドルーム数（bedrooms）のデフォルト値は2であること
入居可能日（availability date）のデフォルト値は3ヶ月後であること

新しい属性¶

ビューの設計を進める前に、モデルの定義に戻ってみましょう。 required=True のようないくつかの属性は、データベースのテーブルスキーマに影響を与えることがわかりました。他の属性は、ビューに影響を与えたり、デフォルト値を提供したりします。

Exercise

フィールドに新しい属性を追加してみましょう。

適切な属性 ( Field を参照) を見つけます。

販売価格（selling price）を読み取り専用に設定します。
入居可能日と販売価格のコピーを防止します。

サーバーを再起動し、ブラウザを更新します。販売価格（selling prices）を設定することができなくなっています。レコードを複製すると、入居可能日（availability date）は空欄になっているはずです。

デフォルト値¶

どのフィールドにもデフォルト値を設定することができます。フィールド定義の中で、 default=X というオプションを追加してください。 X はPythonのリテラル値 (boolean、integer、float、string) か、モデルを受け取って値を返す関数のいずれかです。

name = fields.Char(default="Unknown")
last_seen = fields.Datetime("Last Seen", default=fields.Datetime.now)

name フィールドにはデフォルトで Unknown という値が設定され、 last_seen フィールドには現在の時刻が設定されます。

Exercise

デフォルト値を設定してみましょう。

次のように、適切なデフォルト属性を追加します。

ベッドルーム数のデフォルト値は 2
入居可能日のデフォルト値は 3 ヶ月後

ヒント: これが役立つかも today()

デフォルト値が期待通りに設定されていることを確認してください。

予約済みフィールド¶

参考: このトピックに関連するドキュメントは、予約されたフィールド名にあります。

いくつかのフィールド名は、あらかじめ定義された動作のために予約されています。これらのフィールド名は、関連する動作が必要な場合にモデル上で定義されることがあります。

Exercise

active フィールドを追加してみましょう。

estate.property モデルに active フィールドを追加します。

サーバを再起動し、新しいプロパティを作成し、リストビューに戻ってみると・・・プロパティはリストに表示されません！ active は特定の動作を持つ予約済みフィールドの一例です：レコードが active=False である場合、そのレコードは自動的にあらゆる検索から除外されます。作成したプロパティを表示するには、非アクティブなレコードを特定する方法で検索する必要があります。

Exercise

active フィールドへのデフォルト値の設定

active フィールドに適切なデフォルト値を設定すると、消えなくなります。

デフォルト値として active=False が既存のすべてのレコードに割り当てられていることに注意してください。

Exercise

state フィールドを追加してみましょう。

estate.property モデルに state フィールドを追加します。5つの値は、受け取ったもの、受け取ったもの、受け取ったもの、売却したもの、およびキャンセルしたものです。それは必須でなければならず、コピーしてはならず、デフォルト値は 'New' に設定する必要があります。

必ず正しいタイプを使用してください！

state は、いくつかの UI 機能強化のために後で使用されます。

デフォルトビューのおかげでUIとやり取りできるようになりました。次のステップは明らかです: :doc:`自分のビュー<06_basicviews>`を定義します。

1: ウェブクライアントは、パフォーマンス上の理由から様々なメニューやビューのキャッシュを保持しているため、更新操作が必要です。