Переглянути записи¶

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

Основна структура¶

Базові представлення зазвичай мають спільну мінімальну структуру, визначену нижче. Заповнювачі позначені великими літерами.

<record id="ADDON.MODEL_view_TYPE" model="ir.ui.view">
  <field name="name">NAME</field>
  <field name="model">MODEL</field>
  <field name="arch" type="xml">
    <VIEW_TYPE>
      <views/>
    </VIEW_TYPE>
  </field>
</record>

Типи представлення¶

Форма: Відображати та редагувати дані з одного запису.
Список: Перегляд та редагування кількох записів.
Пошук: Застосуйте фільтри та виконайте пошук. Результати відображаються у поточному списку, канбан… поданні.
Канбан: Відображати записи як «картки», які можна налаштувати як невеликий шаблон.
Qweb: Шаблони звітності, вебсайту…
Графік: Візуалізуйте агрегації за кількома записами або групами записів.
Зведена таблиця: Відображати агрегації у вигляді зведена таблиця.
Календар: Відображати записи як події у щоденному, щотижневому, щомісячному або щорічному календарі.
Когорта Enterprise feature: Відобразити та зрозуміти, як деякі дані змінюються протягом певного періоду часу.
Гант Enterprise feature: Відображати записи у вигляді діаграми Ганта.
Сітка Enterprise feature: Відображають обчислену інформацію в числових комірках; їх важко налаштувати.
Карта Enterprise feature: Відображати записи на карті та маршрути між ними.

Поля¶

Перегляд записів відображає кілька полів.

class odoo.addons.base.models.ir_ui_view.View[source]¶

name¶

Корисний лише як мнемоніка/опис представлення під час пошуку його у певному списку. Більшість назв представлень Odoo починаються з назви доповнення та закінчуються типом представлення, що обговорюється.

вимога: Необов’язково
тип: Char

model¶

Модель, пов’язана з представленням, якщо застосовно.

вимога: Обов’язкове
тип: Char

arch¶

Опис макета представлення залежно від тип представлення.

вимога: Необов’язково
тип: Text

groups_id¶

Групи, яким дозволено використовувати/доступ до поточного перегляду.

Якщо представлення розширює існуюче представлення, розширення буде застосовано лише для певного користувача, якщо цей користувач має доступ до наданого groups_id.

вимога: Необов’язково
тип: Many2many -> Groups

priority¶

Під час запиту представлення із зазначенням model та type повертається відповідне представлення з найнижчим пріоритетом (це представлення за замовчуванням).

Він також визначає порядок застосування представлень під час роздільна здатність представлення. Коли представлення запитується за допомогою id, а його режим не є primary, зіставляється його найближчий батьківський об’єкт з mode = primary.

вимога: Необов’язково
тип: Integer

inherit_id¶

Посилання на батьківський вигляд, до якого буде застосовано inheritance. Його значення використовується за замовчуванням. Вкажіть батьківське представлення за допомогою атрибута ref з ref="ADDON.MODEL_parent_view_TYPE".

Назва доповнення (перед крапкою) не є обов’язковою, якщо успадкування виконується для запису того самого модуля.

Див. Спадкування для отримання додаткової інформації.

вимога: Необов’язково
тип: Many2one

mode¶

Застосовується лише якщо це представлення успадковується від іншого (встановлено inherit_id).

extension¶: Якщо запитується представлення, шукається найближче первинне представлення (через inherit_id). Потім застосовуються всі представлення, що успадковуються від нього, з моделлю цього представлення.

primary¶: Найближчий первинне представлення повністю вирішується (навіть якщо він використовує модель, відмінну від поточної). Потім застосовуються специфікації успадкування, і результат використовується так, ніби це фактична арка цього вигляду.

Випадок, коли потрібно перевизначити mode під час використання inherit_id, - це делегування успадкування. У цьому випадку ваша похідна модель відокремлена від батьківської, і представлення, що збігаються з одним, не збігатимуться з іншим. Припускаючи, що ви успадковуєте від представлення, пов’язаного з батьківською моделлю, і хочете налаштувати похідне представлення для відображення даних з похідної моделі, mode похідного представлення потрібно встановити на primary, оскільки це базове (і, можливо, єдине) представлення для цієї похідної моделі. В іншому випадку правила зіставлення представлень не застосовуватимуться.

Див. Спадкування для отримання додаткової інформації.

вимога: Необов’язково
тип: Selection: extension / primary
Default: extension

Примітка

Поточний контекст і права доступу користувача також можуть впливати на можливості перегляду.

Спадкування¶

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

Успадковувані представлення зазвичай мають спільну структуру, визначену нижче. Заповнювачі позначені великими літерами. Це синтетичне представлення оновлюватиме вузол, на який спрямований XPath, та інший, на який спрямований його назву та атрибути.

<record id="ADDON.MODEL_view_TYPE" model="ir.ui.view">
    <field name="model">MODEL</field>
    <field name="inherit_id" ref="VIEW_REFERENCE"/>
    <field name="mode">MODE</field>
    <field name="arch" type="xml">
        <xpath expr="XPATH" position="POSITION">
            <CONTENT/>
        </xpath>
        <NODE ATTRIBUTES="VALUES" position="POSITION">
            <CONTENT/>
        </NODE>
    </field>
</record>

Поля inherit_id та mode визначають роздільну здатність роздільна здатність представлення. Елементи xpath або NODE вказують на специфікації успадкування. Атрибути expr та position вказують на позицію послідовність успадкування.

Роздільна здатність перегляду¶

Роздільна здатність генерує остаточну arch для запитуваного/збігного primary представлення наступним чином:

якщо представлення має батьківський об’єкт, батьківський об’єкт повністю вирішується, тоді застосовуються специфікації успадкування поточного представлення;
якщо представлення не має батьківського елемента, його arch використовується як є;
дочірні поточного виду з режимом extension шукаються, і їх специфікації успадкування застосовуються за глибиною (спочатку застосовується дочірнє представлення, потім його дочірні, потім його брати і сестри).

Успадкування застосовується відповідно до поля inherit_id. Якщо кілька записів представлень успадковують одне й те саме представлення, порядок визначається priority.

Результат застосування дочірніх представлень дає остаточну arch.

Специфікації успадкування¶

Специфікації успадкування застосовуються послідовно та складаються з:

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

Існує три типи локаторів елементів:

Елемент xpath з атрибутом expr. expr - це вираз XPath 1, застосований до поточної arch, що відповідає першому знайденому вузлу;
Елемент field з атрибутом name, що відповідає першому полю з тим самим name.

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

Примітка
Атрибути position та version ігноруються.

1: Для спрощення зіставлення у представленнях QWeb додано функцію розширення: hasclass(*classes) збігається, якщо вузол контексту містить усі зазначені класи.

Example

<xpath expr="page[@name='pg']/group[@name='gp']/field" position="inside">
    <field name="description"/>
</xpath>

<div name="name" position="replace">
    <field name="name2"/>
</div>

Позиція спадкування¶

Специфікації успадкування приймають необов’язковий атрибут position, за замовчуванням inside, який визначає, як слід модифікувати вузол, що відповідає заданій позиції.

inside¶

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

Example

<notebook position="inside">
    <page string="New feature">
        ...
    </page>
</notebook>

after¶

Вміст специфікації успадкування додається до батьківського вузла, що відповідає, після вузла, що відповідає.

Example

<xpath expr="//field[@name='x_field']" position="after">
    <field name="x_other_field"/>
</xpath>

before¶

Вміст специфікації успадкування додається до батьківського вузла, що відповідає, перед самим вузлом, що відповідає.

Example

<field name=x_field" position="before">
    <field name="x_other_field"/>
</field>

replace¶

Вміст специфікації успадкування замінює вузол, що відповідає заданій таблицею. Будь-який текстовий вузол, що містить лише $0 у вмісті специфікації, замінюється копією вузла, що відповідає заданій таблицею, фактично обгортаючи вузол, що відповідає заданій таблицею.

Example

<xpath expr="//field[@name='x_field']" position="replace">
    <div class="wrapper">
        $0
    </div>
</xpath>

attributes¶

Вміст специфікації успадкування має складатися лише з елементів attribute, кожен з яких має атрибут name та необов’язкове тіло.

Якщо елемент attribute має тіло, до відповідного вузла додається новий атрибут з назвою name, а значенням елемента attribute є текст.
Якщо елемент attribute не має тіла, атрибут, названий після його name, видаляється зі збігаючогося вузла.
Якщо елемент attribute має атрибут add, атрибут remove або обидва, значення атрибута відповідного вузла, названого після name, перераховується для врахування значення(й) add, remove та необов’язкового атрибута separator, який за замовчуванням має значення ,. add включає своє(ї) значення(я), розділені separator. remove видаляє своє(ї) значення(я), розділені separator.

Example

<field name="x_field" position="attributes">
    <attribute name="invisible">True</attribute>
    <attribute name="class" add="mt-1 mb-1" remove="mt-2 mb-2" separator=" "/>
</field>

move¶

Атрибут position="move" встановлюється для вмісту специфікації успадкування, щоб вказати, як вузли переміщуються відносно локатора елементів специфікації успадкування, для якого також має бути встановлено атрибут position зі значеннями inside, replace, after або before.

Example

<xpath expr="//@target" position="after">
    <xpath expr="//@node" position="move"/>
</xpath>

<field name="target_field" position="after">
    <field name="my_field" position="move"/>
</field>

Модель commons¶

class odoo.addons.base.models.ir_ui_view.View[source]

Model.get_views(views, options=None)¶

Повертає значення fields_views заданих представлень, а також поля поточної моделі та, за бажанням, її фільтри для заданої дії.

Повернення методу може залежати лише від запитуваних типів представлень, прав доступу (представлення чи інші записи), правил доступу до представлень, опцій, мови контексту та TYPE_view_ref (інші значення контексту використовувати не можна).

Вирази Python, що містяться у представленнях або представляють домени (у полях Python), будуть оцінюватися клієнтом з усіма значеннями контексту, а також значеннями записів, які він має.

Параметри

views – список [view_id, view_type]
options (dict) – необов’язкові логічні прапорці словника, встановлені на увімкнення: toolbar включає контекстні дії під час завантаження fields_views load_filters повертає фільтри моделі action_id ідентифікатор дії для отримання фільтрів, інакше завантажує глобальні фільтри або модель

Повертає

словник з fields_views, полями та, за бажанням, фільтрами

Model.get_view([view_id | view_type='form'])¶

Отримати детальний склад запитуваного представлення, наприклад, модель, архітектуру представлення.

Параметри

view_id (int) – id представлення або None
view_type (str) – тип представлення для повернення, якщо view_id дорівнює None („form“, „tree“, …)
options (dict) – логічні параметри для повернення додаткових функцій: - boolean mobile: true, якщо веб-клієнт наразі використовує адаптивний мобільний вигляд (для використання канбан-представлення замість спискового представлення для полів x2many)

Повертає

склад запитаного представлення (включаючи успадковані представлення та розширення)

Тип повернення

dict

Викликає

AttributeError –
- якщо успадковане подання має невідому позицію для роботи, крім „before“, „after“, „inside“, „replace“
- якщо в батьківському представленні знайдено тег, відмінний від „position“
Invalid ArchitectureError – якщо для структури визначено тип представлення, відмінний від форми, дерева, календаря, пошуку тощо…

Редагувати на GitHub