Розділ 6: Нарешті, інтерфейс для гри з

Тепер, коли ми створили нашу нову модель та її відповідні права доступу, настав час взаємодії з інтерфейсом користувача.

Наприкінці цієї глави ми створимо кілька меню для доступу до типового списку та представленні форми.

Файли даних (XML)

Довідка: документацію, пов’язану з цією темою, можна знайти в Файли даних.

У Розділ 5: Безпека - короткий вступ ми додали дані за допомогою файлу CSV. Формат CSV зручний, коли дані для завантаження мають простий формат. Якщо формат є складнішим (наприклад, завантажується структура перегляду або шаблон ел. пошти), ми використовуємо формат XML. Наприклад, це поле довідки містить теги HTML. Хоча можна було б завантажити такі дані через файл CSV, зручніше використовувати файл XML.

XML-файли мають бути додані до тих самих папок, що й CSV-файли, і визначені подібним чином у __manifest__.py. Вміст файлів даних також послідовно завантажується під час встановлення або оновлення модуля, тому всі зауваження, зроблені для файлів CSV, справедливі для файлів XML. Коли дані пов’язані з представленнями, ми додаємо їх до папки views.

У цьому розділі ми завантажимо нашу першу дію та меню через файл XML. Дії та меню є стандартними записами в базі даних.

Примітка

Коли важлива продуктивність, перевага віддається формату CSV перед форматом XML. Це стосується Odoo, де завантаження файлу CSV відбувається швидше, ніж завантаження файлу XML.

В Odoo інтерфейс користувача (дії, меню та представлення) значною мірою визначається створенням і створенням записів, визначених у файлі XML. Загальний шаблон - Меню > Дія > Представлення. Для доступу до записів користувач переміщається по декількох рівнях меню; найглибший рівень - це дія, яка запускає відкриття списку записів.

Дії

Довідка: документацію, пов’язану з цією темою, можна знайти в Файли даних.

Примітка

Ціль: наприкінці цього розділу дія має бути завантажена в систему. Ми ще нічого не побачимо в інтерфейсі користувача, але файл має бути завантажено в журнал:

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

Дії можна запустити трьома способами:

1. натисканням пунктів меню (пов’язаних із певними діями)

2. натисканням кнопок у поданнях (якщо вони пов’язані з діями)

3. як контекстні дії на об’єкт

У цій главі ми розглянемо лише перший випадок. Другий випадок буде розглянуто в пізнішій главі, тоді як останній є темою розширеної теми. У нашому прикладі Real Estate ми хотіли б пов’язати меню з моделлю estate.property, щоб ми могли створити новий запис. Дію можна розглядати як зв’язок між меню та моделлю.

Базовою дією для нашої 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">tree,form</field>
</record>

• id є зовнішнім ідентифікатором. Його можна використовувати для посилання на запис (не знаючи його ідентифікатора в базі даних).

• model має фіксоване значення ir.actions.act_window (Дії вікна (ir.actions.act_window)).

• name - це назва дії.

• res_model - це модель, до якої застосовується дія.

• view_mode – представлення, які будуть доступні; у цьому випадку це представлення списку (дерева) і форми. Ми побачимо пізніше, що можуть бути інші режими представлення.

Приклади можна знайти всюди в Odoo, але цей є хорошим прикладом простої дії. Зверніть увагу на структуру файлу даних XML, оскільки він знадобиться вам у наступній вправі.

Exercise

Додайте дію.

Створіть файл estate_property_views.xml у відповідній папці та визначте його у файлі __manifest__.py.

Створіть дію для моделі estate.property.

Перезапустіть сервер, і ви побачите завантажений файл у журналі.

Меню

Довідка: документацію, пов’язану з цією темою, можна знайти в Файли даних.

Примітка

Ціль: наприкінці цього розділу має бути створено три меню та відображено типове представлення:

Щоб зменшити складність оголошення меню (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. Як зазначалося раніше, дію можна розглядати як зв’язок між меню і моделлю.

Однак меню завжди мають певну архітектуру, і на практиці є три рівні меню:

1. Кореневе меню, яке відображається в перемикачі додатків (перемикач додатків Odoo Community є спадним меню)

2. Меню першого рівня, що відображається у верхній панелі

3. Меню дії

   

Найпростіший спосіб визначити структуру – це створити її у файлі 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>

Назву для третього меню взято з назви action.

Exercise

Додайте меню.

Створіть файл estate_menus.xml у відповідній папці та визначте його у файлі __manifest__.py. Пам’ятайте про послідовне завантаження файлів даних ;-)

Створіть три рівні меню для дії estate.property, створеної в попередній вправі. Очікуваний результат див. у Ціль цього розділу.

Перезапустіть сервер і оновіть браузер1. Тепер ви повинні побачити меню, і ви навіть зможете створити свою першу рекламу нерухомості!

Поля, атрибути та представлення

Примітка

Ціль: у кінці цього розділу ціна продажу має бути лише для читання, а кількість спалень і дата доступності мають мати значення за замовчуванням. Крім того, значення продажної ціни та дати доступності не копіюватимуться, якщо запис буде дубльовано.

Зарезервовані поля active і state додаються до моделі estate.property.

Поки що ми використовували лише загальний вигляд для наших оголошень про нерухомість, але в більшості випадків ми хочемо налаштувати представлення. У Odoo є багато можливих тонких налаштувань, але зазвичай першим кроком є переконатися, що:

• деякі поля мають значення за замовчуванням

• деякі поля доступні лише для читання

• деякі поля не копіюються при дублюванні запису

У нашому бізнесі з нерухомістю ми хотіли б наступного:

• Ціна продажу має бути лише для читання (вона буде автоматично заповнена пізніше)

• При дублюванні запису не слід копіювати дату наявності та продажну ціну

• За замовчуванням має бути 2 спальні

• Стандартна дата доступності має бути через 3 місяці

Деякі нові атрибути

Перш ніж рухатися далі з дизайном перегляду, давайте повернемося до визначення нашої моделі. Ми побачили, що деякі атрибути, такі як required=True, впливають на схему таблиці в базі даних. Інші атрибути впливатимуть на перегляд або забезпечуватимуть значення за замовчуванням.

Exercise

Додайте нові атрибути до полів.

Знайдіть відповідні атрибути (див. Field), щоб:

• установіть ціну продажу лише для читання

• запобігти копіюванню дати наявності та значень продажної ціни

Перезапустіть сервер і оновіть браузер. Ви не зможете встановлювати будь-які продажні ціни. Під час дублювання запису дата доступності має бути порожньою.

Значення по замовчуванню

Будь-якому полю можна надати значення за умовчанням. У визначенні поля додайте опцію default=X, де X є значенням літералу Python (логічне значення, ціле число, число з плаваючою точкою, рядок) або функцією, яка приймає модель і повертає значення:

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

Поле name матиме значення „Unknown“ за замовчуванням, тоді як поле last_seen буде встановлено як поточний час.

Exercise

Встановіть значення за замовчуванням.

Додайте відповідні атрибути за замовчуванням, щоб:

• стандартна кількість спалень - 2

• за замовчуванням дата доступності через 3 місяці

Порада: це може вам допомогти: today()

Переконайтеся, що значення за замовчуванням встановлено належним чином.

Зарезервовані поля

Довідка: документацію, пов’язану з цією темою, можна знайти в Зарезервовані назви полів.

Кілька назв полів зарезервовано для попередньо визначеної поведінки. Вони повинні бути визначені в моделі, коли потрібна відповідна поведінка.

Exercise

Додати активне поле.

Додайте поле active до моделі estate.property.

Перезапустіть сервер, створіть нову властивість, а потім поверніться до списку… Властивість не буде в списку! active є прикладом зарезервованого поля з особливою поведінкою: коли запис має active=False, він автоматично видаляється з будь-якого пошуку. Щоб відобразити створену властивість, вам потрібно буде спеціально шукати неактивні записи.

Exercise

Установіть значення за умовчанням для активного поля.

Встановіть відповідне значення за умовчанням для поля active, щоб воно більше не зникало.

Зауважте, що значення за умовчанням active=False було призначено всім існуючим записам.

Exercise

Додайте поле стану.

Додайте поле state до моделі estate.property. Можливі п’ять значень: нова, пропозиція отримана, пропозиція прийнята, продана та скасована. Він має бути обов’язковим, його не можна копіювати та мати стандартне значення „Новий“.

Переконайтеся, що використовуєте правильний тип!

state буде використано пізніше для кількох покращень інтерфейсу користувача.

Тепер, коли ми можемо взаємодіяти з інтерфейсом користувача завдяки представленням за замовчуванням, наступний крок очевидний: ми хочемо визначити наші власні представлення.

1

Потрібне оновлення, оскільки веб-клієнт зберігає кеш різних меню та представлень з міркувань продуктивності.