Основний реквізит форми. Реквізити керованої форми (1Cv8) 1с керовані форми додати реквізит програмно

Реквізити форми

Набір реквізитів форми описує склад даних, які відображаються, редагуються чи зберігаються у формі. При цьому реквізити форми самі по собі не забезпечують можливості відображення та редагування даних. Для відображення та редагування служать елементи форми (дивіться розділ «Елементи форми» цього розділу), пов'язані з реквізитами форми. Сукупність всіх реквізитів форми називатимемо даними форми.

Важливо!Необхідно пам'ятати, що на відміну від звичайних форм, всі дані керованої форми повинні бути описані у вигляді реквізитів. Не допускається використання змінних модуля форми як джерела даних для елементів форми.

Є можливість призначити Основний реквізит форми, тобто реквізит, який визначатиме стандартну функціональність форми (розширення форми). Слід пам'ятати, що основний реквізит у форми може лише один.

Розширення форми- це додаткові властивості, методи та параметри форми об'єкта Керована Форма, характерні для об'єкта, що є основним елементом форми.

У процесі розробки форми можна явно задати можливість перегляду та редагування конкретних реквізитів форми, у розрізі ролей, за допомогою властивостей Перегляд та Редагування (докладніше дивіться розділ «Рольове налаштування форми» розділу «Редактори»). Крім того, доступність того чи іншого реквізиту в самій формі можна налаштовувати за допомогою функціональних опцій (докладніше про функціональні опції можна переглянути в розділі «Керування інтерфейсом конфігурації»).

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

Типи даних, доступні в керованій формі

Керована форма відрізняється від звичайної форми також типами даних, з якими вона працює. Якщо звичайна форма працює з більшістю типів, які надає 1С:Підприємство (у тому числі й виду Довідник Об'єкт, ДокументОб'єкт тощо), то в керованій формі можна виділити такі категорії типів:

  • типи, які безпосередньо використовуються у формі – це ті типи, які існують на стороні тонкого та веб-клієнта (наприклад, Число, Довідник Посилання. Товари, Графічна Схема, Табличний Документ);
  • типи, що будуть перетворені на спеціальні типи даних – типи даних керованої форми. Такі типи відображаються у списку реквізитів форми у круглих дужках, наприклад (Довідник Об'єкт. Товари);
  • динамічний список (докладніше див. розділ «Динамічний список» цього розділу).

Перетворення прикладних об'єктів у дані форми

Деякі прикладні типи (такі як Довідник Об'єкт тощо) не існують на стороні тонкого та Веб-клієнтів (докладніше див. розділ «Концепція керованого додатка»). Тому для представлення у формі таких прикладних типів у платформі запроваджено спеціальні типи даних, призначені для роботи в керованих формах. Ця особливість керованого додатка обумовлює необхідність виконувати перетворення прикладних об'єктів на дані форми (і назад).

Використовуються такі типи даних:

  • Дані Форми Структура – ​​містить набір властивостей довільного типу. Властивості можуть бути інші структури, колекції або структури з колекціями. Таким типом представляється, наприклад, у формі Довідник Об'єкт.
  • Дані Форми Колекція – це список типізованих значень, схожий на масив. Доступ до елемента колекції здійснюється за індексом або ідентифікатором. Доступ за ідентифікатором може бути відсутнім у деяких випадках. Це зумовлено типом прикладного об'єкта, представленого цією колекцією. Ідентифікатор може бути будь-яке ціле число. Таким типом представляється, наприклад, у формі таблична частина.
  • ДаніФормиСтруктураСколекцією – це об'єкт, який представлений у вигляді структури та колекції одночасно. З ним можна поводитися як із будь-якою з цих сутностей. Таким типом представляється, наприклад, у формі набір записів.
  • ДаніФормиДерево - об'єкт призначений для зберігання ієрархічних даних.

Прикладний об'єкт представлений або одним або кількома елементами даних форми. У загальному вигляді ієрархія та склад даних форми залежать від складності та взаємозв'язку прикладних об'єктів керованої форми.

Наприклад, документ, що містить табличну частину, буде представлений об'єктом типу Дані Форми Структура (власне документ), якому підпорядкований об'єкт типу Дані Форми Колекція (таблична частина документа).

Важливо!Під час розробки конфігурації важливо пам'ятати, що прикладні об'єкти доступні лише на сервері, тоді як об'єктами даних форм можна скористатися і сервері, і клієнта.

Передача даних між клієнтською та серверною частинами керованої форми

Фактично можна сказати, що дані форми – це уніфіковане представлення даних різних прикладних об'єктів, із якими форма працює однаково і які є і сервері, і клієнта. Тобто форма містить деяку «проекцію» даних прикладних об'єктів у вигляді своїх власних типів даних та виконує перетворення між ними за потреби. Однак якщо розробник конфігурації реалізує свій алгоритм обробки даних, то перетворення даних (із спеціалізованих типів в прикладні і назад) він повинен виконувати самостійно.

Під час редагування реквізитів форми у спеціалізованому редакторі (докладніше див. розділ «Реквізити форми» глави «Редактори») можна впливати на передачу даних між клієнтом і сервером під час роботи форми. Для цього слугує колонка редактора реквізитів. Використовувати завжди. Дія цієї якості відрізняється для трьох типів реквізитів:

  • Для реквізиту, підпорядкованого динамічному списку (колонці динамічного списку):
    • властивість включено – реквізит завжди зчитується з бази даних і входить у дані форми;
    • властивість вимкнено – реквізит зчитується з бази даних і входить у дані форми лише тоді, коли є видимий на даний момент елемент форми, пов'язаний з реквізитом або його підлеглим реквізитом.
  • Для реквізиту, підпорядкованого колекції рухів:
    • властивість включено – руху документа зчитуються з бази даних та будуть присутні у даних форми;
    • властивість виключено – руху документа нічого очікувати зчитуватися з бази даних і потраплять у дані форми (якщо немає елемента форми, посилається руху документа).
  • Інші реквізити форми:
    • властивість включено – реквізит буде у даних форми незалежно від цього, є чи ні хоч один елемент форми, що з реквізитом чи його підлеглим реквізитом;
    • властивість вимкнено – реквізит буде у даних форми лише тому випадку, якщо є елемент форми, що з реквізитом чи його підлеглим реквізитом. На відміну від реквізитів динамічного списку, тут відіграє ролі видимість елемента, що з реквізитом.

Примітка. Слід пам'ятати, що властивість, встановлена ​​у батьківського реквізиту, діє всі підлеглі реквізити. Наприклад, якщо властивість Використовувати завжди знято у табличній частині документа, то система вважає, що ця властивість знята і у всіх підлеглих реквізитів (попри фактичний стан якості).

Методи для перетворення даних прикладних об'єктів у дані форми

Для конвертування прикладних об'єктів у дані форми та назад існує набір глобальних методів:

  • ЗначенняДані Форми(),
  • ДаніФормиЗначення(),
  • КопіюватиДаніФорми().

Важливо!Методи, які працюють із прикладними об'єктами, доступні лише у серверних процедурах. Метод для копіювання значень між даними форми доступний на сервері та на клієнті, оскільки не вимагає прикладних об'єктів як параметри.

Під час конвертування даних форми в прикладний об'єкт потрібно враховувати їхню сумісність.

  • ЗначенняДанныеФорми() – перетворює об'єкт прикладного типу на дані форми;
  • ДаніФормиЗначення() – перетворює дані форми на об'єкт прикладного типу;
  • КопіюватиДаніФорми() – здійснює копіювання даних форми, що володіють сумісною структурою. Повертає значення Істина, якщо копіювання зроблено, або Брехня, якщо структура об'єктів несумісна.

Примітка. При виконанні стандартних дій (відкриття форми, виконання стандартної команди Записати тощо) форми з основним реквізитом перетворення виконується автоматично.

Наведемо приклад, як використовувати перетворення даних у власних алгоритмах.

&На Сервері Процедура ПриСтворенніНаСервері(Відмова, СтандартнаОбробка)

Об'єктТовар = Довідники.Товари.ЗнайтиЗа найменуванням («Кавник»). ЗначенняДані Форми(Об'єктТовар, Об'єкт);

КінецьПроцедури

&НаКлієнті Процедура Записати()

ЗаписатиНа Сервері();

КінецьПроцедури

&НаСервері Процедура ЗаписатиНаСервері()

Об'єктТовар = ДаніФормиЗначення(Об'єкт, Тип(«ДовідникОб'єкт.Товари»)); Об'єктТовар.Записати();

КінецьПроцедури

Також в об'єкті Керована Форма існують методи, доступні на сервері:

  • ЗначенняВРеквізитФорми() – виконує перетворення об'єкта прикладного типу на заданий реквізит форми.
  • РеквізитФормиЗначення() – перетворює реквізит даних форми на об'єкт прикладного типу.

Використання даних методів зазвичай зручніше, оскільки вони мають, наприклад, інформацію про тип реквізиту форми. Крім того, метод РеквізитФормиЗначення() виконує встановлення відповідності даних форми та об'єкта, яка використовується при формуванні повідомлень. Докладніше про це можна прочитати у розділі «Сервісні можливості навігації».

Наведемо приклад використання цих методів.

&НаСервері Процедура ПерерахуватиНаСервері()

// Перетворює реквізит Об'єкт на прикладний об'єкт. Документ = РеквізитФормиЗначення(«Об'єкт»); // Виконує перерахунок методом, визначеним у модулі документа. Документ.Перелічити(); // Перетворює прикладний об'єкт назад у реквізит. Значення ВРеквізитФорми (Документ, «Об'єкт»);

КінецьПроцедури

Програмний інтерфейс

ДаніФормиДерево (FormDataTree)

  • ЗнайтиПоІдентифікатору (FindById)
  • ОтриматиЕлементи (GetItems)

Опис:

Призначений для моделювання дерева даних керованої форми.

Цей об'єкт може бути серіалізований з XDTO. Тип XDTO, відповідний даному об'єкту визначається просторі імен. Ім'я типу XDTO:

ОтриматиЕлементи (GetItems)

Синтаксис:

ОтриматиЕлементи()

Значення, що повертається:

Тип: ДаніФормиКолекціяЕлементівДерева.

Опис:

Отримує колекцію елементів дерева верхнього рівня.

Наявність: клієнт, сервер, тонкий клієнт, веб-клієнт.

ЗнайтиПоІдентифікатору (FindById)

Синтаксис:

ЗнайтиПоІдентифікатору(<Идентификатор>)

Параметри:

<Идентификатор>(обов'язковий)

Тип: Число. Ідентифікатор дерева елемент.

Значення, що повертається:

Тип: ДаніФормиЕлементДерева.

Опис:

Отримує елемент колекції за ідентифікатором.

Наявність: клієнт, сервер, тонкий клієнт, веб-клієнт.

ДаніФормиЕлементДерева (FormDataTreeItem)

Властивості:

<Имя свойства> (<Имя свойства>)

  • Отримати Ідентифікатор (GetId)
  • Отримати Батька (GetParent)
  • ОтриматиЕлементи (GetItems)
  • Властивість (Property)

Опис:

Елемент дерева даних форми.

ДаніФормиКолекціяЕлементівДерева (FormDataTreeItemCollection)

Елементи колекції: ДаніФормиЕлементДерева

Для об'єкта доступний обхід колекції за допомогою оператора Для кожного … З … Цикл. Під час обходу вибираються елементи колекції. Можливе звернення до елемента колекції за допомогою оператора [...]. Як аргумент передається індекс елемента.

  • Вставити (Insert)
  • Додати (Add)
  • Індекс (IndexOf)
  • Кількість (Count)
  • Очистити (Clear)
  • Отримати (Get)
  • Зрушити (Move)
  • Видалити (Delete)

Опис:

Колекція деревини елементів.

Наявність: клієнт, сервер, тонкий клієнт, веб-клієнт.

Див. також:

  • ДаніФормиЕлементДерева, метод ОтриматиЕлементи
  • ДаніФормиДерево, метод ОтриматиЕлементи

Особливості роботи з деревом значень

Оновлення дерева

Існує проблема падінняплатформи під час оновлення дерева.

Якщо в дереві було розгорнуто будь-який вузол і обрано підлеглий вузол, то при оновленні дерева функцією ЗначенняДаніФормивідбувається падіння платформи.

Рішення: Перед оновленням потрібно очищати дерево.

Наприклад:

&НаСервері Процедура ОчиститиДерево(елементи) Для кожного елемент з елемента Цикл ОчиститиДерево(елемент.ОтриматиЕлементи()); КінецьЦикл; елементи.Очистити(); КінецьПроцедури

&НаСервері Процедура ЗаповнитиДеревоПонятий() дзПонятия = срВластивості.ПобудуватиДеревоПонятий(НаДату, Мета.ПоточнаяИБ()); Очистити Дерево (Дерево Понять. Отримати Елементи ()); ЗначенняДані Форми(дзПоняття, ДеревоПонять); КінецьПроцедури

&НаКлієнті Процедура НаДатуПриЗміні(Елемент) ЗаповнитиДеревоПонятий(); КінецьПроцедури

Платформа 1С: Підприємство дозволяє програмно додавати та змінювати елементи керованої форми. Розберемося для чого це може знадобитися.

Програмна модифікація форми може знадобитися в кількох випадках:

  • При доопрацюванні типових конфігурацій для полегшення процедури подальшого оновлення. У цьому випадку буде змінено лише модуль форми. Модулі набагато простіше оновлювати, ніж форму.
  • За реалізації деяких загальних алгоритмів. Наприклад, у підсистемі "Заборона редагування реквізитів об'єктів" для всіх підключених до підсистеми об'єктів передбачено програмне створення кнопки для включення можливості редагування реквізитів.
  • За реалізації деяких специфічних алгоритмів. Наприклад, у довіднику Номенклатура створюються поля для редагування додаткових реквізитів.

У керованій формі можна програмно додати, змінити та видалити:

  • реквізити;
  • локальні команди;
  • елементи.

Всі ці операції можливі лише на сервері.

Програмна зміна форми має обмеження:

  • Видалити можна лише програмно додані реквізити/команди/елементи. Не можна програмно видалити об'єкти, створені у конфігураторі.
  • Не можна призначити реквізит головним.

Зміна команд форми

Для керування складом команд у об'єкта КерованаФормає колекція Команди

    Додати (< ИмяКоманды >)

    Кількість ()

    Знайти (< ИмяКоманды >)

    видалити (< Команда >)

Колекція команди доступна як на клієнті, так і на сервері. Змінювати колекцію (методи Додати () та Видалити () ) можна лише на сервері. Шукати та отримувати кількість елементів (методи Знайти () та Кількість () ) можна як на клієнті, так і на сервері.

Як приклад роботи з командами форми створимо нову команду Історія Змін із заголовком «Історія змін…», яка буде викликати обробник ВідобразитиІсторію(). Створення виконується під час відкриття форми.

&На сервері
Процедура При створенні на сервері (Відмова, Стандартна Обробка)
Команда = Команди. Додати( "Історія змін");
Команда . Дія =;
Команда . Заголовок = "Історія змін…";
КінецьПроцедури
&На Клієнті
Процедура Підключається_ВідобразитиІсторію(Команда)
// дії команди
КінецьПроцедури

Обробник команди повинен розташовуватися у формі та мати директиву компіляції & На Клієнті.

Зміна реквізитів форми

Читання складу реквізитів форми виконується функцією ОтриматиРеквізити(< Путь >) , що повертає масив типу РеквізитФорми . Параметр функції вказує шлях до батьківського реквізиту (у вигляді рядка). Якщо параметр опущено або вказано порожній рядок, повертаються реквізити верхнього рівня.

Зміна реквізитів виконується методом ЗмінитиРеквізити(<Реквізити, що додаються>, <ВидаленіРеквізити>) об'єкта КерованаФорма. У параметри Реквізити, що додаютьсяі ВидаленіРеквізитипередаються масиви з елементами типу РеквізитФорми.

Увага!

Процес зміни складу реквізитів є досить ресурсомістким. Фактично виконується перестворення форми. У зв'язку з цим робота з реквізитами форми виконується пакетному режимі.

Створимо новий реквізит форми з ім'ям Покупець:


Реквізити, що додаються = Новий Масив;
Реквізити, що додаються. Додати(Новий РеквізитФорми(«Покупець», Новий Опис Типів («Довідник Посилання.Контрагенти»), «Клієнт»));

// Зміни складу реквізитів
);

Зміна елементів форми

Для керування складом елементів у об'єкта КерованаФормає колекція Елементи. Колекція має кілька методів:

    Вставити (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

    Додати (< Имя>, < ТипЭлемента>, < Родитель >)

    Кількість ()

    Знайти (< Имя >)

    Перемістити(< Элемент>, < Родитель>, < МестоРасположения >)

    видалити (< Элемент >)

Колекція Елементи доступні як на клієнті, так і на сервері. Змінювати колекцію (методи Вставити () , Додати () , Перемістити () та Видалити () ) можна лише на сервері. Шукати та отримувати кількість елементів (методи Знайти () та Кількість () ) можна як на клієнті, так і на сервері. Елементами колекції можуть бути:

  • ГрупаФорми;
  • ТаблицяФорми;
  • ПолеФорми;
  • КнопкаФорми.

Елементам форми можна програмно призначити обробники подій. Для цього призначений метод Встановити Дію (< ИмяСобытия>, < Действие >) .

Розглянемо кілька найпоширеніших практично прикладів роботи з командами, реквізитами і елементами форми.

Додавання команди та пов'язаної з нею кнопки:

// Створення команди
Команда = Команди. Додати( "Історія змін");
Команда . Дія = «Підключається_Відобразити Історію»; // У формі має бути процедура із зазначеним найменуванням
Команда . Заголовок = "Історія змін…";
// Створення кнопки та зв'язок її з командою
Елемент = Елементи. Додати( "Історія змін", Тип («КнопкаФорми»));
Елемент.Ім'яКоманди = "Історія змін";

Додавання реквізиту та пов'язаного з ним поля введення:

// Опис реквізитів, що додаються
Реквізити, що додаються = Новий Масив;
Реквізити, що додаються. Додати(Новий РеквізитФорми («Покупець» , Новий ОписТипів ( «ДовідникПосилання.Контрагенти»), «Клієнт»));
// Зміна складу реквізитів
ЗмінитиРеквізити(ДодаютьсяРеквізити));
// Створення поля введення та зв'язок з реквізитом
Елемент = Елементи. Додати («Покупець», Тип («ПолеФорми»));
Елемент . Вигляд = ВидПоляФорми. Поле введення;
Елемент . ШляхДаним= «Покупець»;

Призначення елемента форми обробника події:

ЕлементПокупець. Встановити Дію("При зміні" , «Підключається_ПокупецьПриЗміні»);

&На Клієнті
Процедура Підключається_ПокупецьПриЗміні(Елемент)
// Дії події
КінецьПроцедури

Увага!

Процедурам, які встановлюються як обробники подій з коду за допомогою методу Встановити Дію(), рекомендується задавати префікс Підключений_.

Увага!

Завантажити обробку з прикладами програмного пошуку та зміни реквізитів, команд та елементів керованої форми можна.

Реквізити форми забезпечують її зв'язок із даними. При цьому один (і лише один) із реквізитів може бути призначений основним; він не обов'язково може бути такого типу даних, до об'єкта якого ми малюємо форму. Але від типу даних основного реквізиту залежатиме поведінка форми. Крім зміни поведінки форми, відбувається зміна контексту модуля форми. Поряд з методами та властивостями форми, у ньому стають доступні методи та властивості об'єкта, що є значенням основного реквізиту. Важливо, що форми типу "Довільна форма" не мають основного реквізиту. У цьому випадку поведінка форми визначається лише налаштуваннями користувача. Розглянемо питання щодо основних реквізитів.

Запитання 10.05 іспиту 1С: Професіонал з платформи. Навіщо служить основний реквізит форми?

  1. Визначає джерело даних для форми загалом
  2. Визначає стандартні можливості платформи для роботи форми з даними типу, заданого у основного реквізиту
  3. Для забезпечення можливості програмного звернення до реквізитів об'єкта з локального контексту форми
  4. Забезпечує візуалізацію реквізитів об'єкта на діалозі форми
  5. Вірні 2 та 3
  6. Вірні 1 та 2

Правильна відповідь шоста, див. вище.


Запитання 10.06 іспиту 1С: Професіонал з платформи. Навіщо потрібні реквізити форми?
  1. Для опису складу даних, які відображаються, редагуються або зберігаються у формі
  2. Для відображення та редагування даних у формі
  3. Вірні 1 та 2

Правильна відповідь третя - і те, й інше.

Питання 10.07 іспиту 1С: Професіонал з платформи. Щоб довільній керованій формі призначити основний реквізит...

  1. Необхідно у властивостях реквізиту форми встановити прапорець "Основний реквізит"
  2. Необхідно заповнити властивість "Дані" форми, вибравши необхідний реквізит форми

Правильна відповідь другий:

Питання 10.08 іспиту 1С: Професіонал з платформи. Щоб довільній звичайній формі призначити основний реквізит...
  1. форму потрібно зробити основною, основний реквізит при цьому визначається автоматично
  2. Необхідно у властивостях реквізиту форми встановити прапорець "Основний реквізит"
  3. потрібно увійти в меню "Правка", пункт "Основний реквізит" та вибрати потрібне значення
  4. Необхідно заповнити властивість "Дані" форми, вибравши необхідний реквізит форми

Правильна відповідь четверта:

Основний реквізит виділяється жирним:

Запитання 10.09 іспиту 1С: Професіонал з платформи. За наявності одного основного реквізиту форми, чи можна додати ще один основний реквізит?
  1. Це неможливо
  2. Можна за допомогою призначення відповідного значення якості реквізиту форми
  3. Можна лише програмно, звертаючись до об'єкта "Форма"
  4. Можна за допомогою додавання ще одного значення до відповідної властивості форми

Правильна відповідь перша, основний реквізит суворо один, т.к. зв'язок з об'єктом має бути однозначним.

Питання 10.113 іспиту 1С: Професіонал з платформи. Який із реквізитів форми, представленої на малюнку, є основним?

  1. СписокКурсовВалют
  2. ДовідникОб'єкт
  3. Форми довідників не мають основного реквізиту
  4. У форм довідників всі основні реквізити
Правильна відповідь друга - та, що жирна.

Управління формою здійснюється за допомогою різних елементів форми, що розташовані ієрархічно на закладці Елементиконструктор форм. Найголовнішим елементом є сама форма, розташована вгорі ієрархії елементів, інші елементи їй підпорядковані.

Усі елементи форми можна розділити п'ять груп: поля, елементи угруповання, кнопки, декорації та таблиці. У своїх статтях я розберу кожну групу. У цій статті ми почнемо вивчати один із видів елемента поле. поле введенняале перед цим навчимося додавати елемент на форму.

Додавання елементів на форму

Робиться це досить просто: необхідно виділити елемент Формау вікні Елементи конструктора форми та натиснути на кнопку «Додати». Після цього відкриється вікно, в якому потрібно вибрати потрібний тип елемента

Після вибору елемент потрібного з'явиться у вікні Елементи.

Елемент керованої форми Поле

Розберемо елемент керованої форми Поле. Цей елемент необхідний для введення інформації формою. А також для відображення будь-якої інформації. Після того, як ви додасте цей елемент на форму, праворуч відкриється палітра властивостей елемента форми. Поки що Вас мають цікавити дві властивості – ШляхКДанним та Вид.

Як ПутьКДанным розробник може пов'язати елемент форми з необхідним реквізитом форми. Зверніть увагу, що після того, як було додано елемент Поле введенняна форму він не відобразився на самій формі. Це сталося тому, що наш новий елемент не пов'язаний із . Для прикладу я створив на формі обробки кілька реквізитів з різними примітивними типами та один реквізит із посилальним типом.

Тепер зв'яжемо наш нещодавно доданий елемент форми з одним із реквізитів, для цього виберемо потрібний реквізит із властивості елемента ШляхКДаним.

Після цього заповняться властивості ШляхКДаним і Вигляд, а сам елемент відобразиться у поданні форми.

Зверніть увагу на властивість елемента Вид. За допомогою цієї характеристики визначається функціональність поля введення. Можна вибрати різні значення цієї властивості.

Залежно від вибраного значення визначатиметься функціонал. На рисунках вище вибрано значення – поле введення, тобто. ми можемо вводити будь-які значення в поле введення, а якщо вибрати значення поле написи, то нічого вводити ми не зможемо.

Це значення властивостей Видполя введення зручно вибирати, коли потрібно просто показати довідкову інформацію користувачеві.

Тепер додамо новий елемент форми з типом Поле введенняі зв'яжемо його з реквізитом РеквзитДатаза допомогою вже знайомої нам властивості ШляхКДаним

Як Ви бачите вид поля введення змінився, а також зміниться можливий вибір значень властивості Вид.

Отже, робимо висновок – функціональність поля введення залежить від типу реквізиту.

Для реквізиту з типом Бульовобудуть доступні такі значення властивості Вид.

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

Докладніше робота з елементами форми на практичних прикладах дається у книзі «Основи розробки в 1С:Таксі. Розробка керованого додатка за 12 кроків».

Іноді здається, що вивчити мову програмування у 1С складно та важко. Насправді програмувати в 1С легко. Допоможуть Вам легко та швидко освоїти програмування у 1С мої книги: та «Основи розробки у 1С: Таксі»

Вивчіть програмування в 1С за допомогою моєї книги «Програмувати в 1С за 11 кроків»

  1. Без складних технічних термінів.
  2. Понад 700 сторінок практичного матеріалу.
  3. Кожне завдання супроводжується малюнком (скриншот).
  4. Збірник завдань для домашнього опрацювання.
  5. Книга написана зрозумілою та простою мовою – для новачка.

Ця книга підійде тим, хто вже почав програмувати та відчуває певні складнощі з цією темою і тим, хто вже давно програмує, але жодного разу ще не працював із керованими формами 1С

  1. без складних технічних термінів;
  2. Понад 600 сторінок практичного матеріалу;
  3. Кожен приклад супроводжується малюнком (скриншот);
  4. Книга надсилається на електронну пошту у форматі PDF. Можна відкрити будь-який пристрій!

Промо-код на знижку в 15% 48PVXHeYu


Якщо Вам допоміг цей урок вирішити якусь проблему, сподобався чи виявився корисним, то Ви можете підтримати мій проект, перерахувавши будь-яку суму:

можна сплатити вручну:

Яндекс.Гроші — 410012882996301
Web Money - R955262494655

Вступайте до моїх груп.

Data Transfer Object до структуризації коду, керованої форми в середовищі 1С 8.2.

Вступ

Почнемо з невеликого опису поняття «керована форма» та пов'язаних концепцій платформи 1С. Файли платформи можуть пропустити цей розділ.

У 2008 році стала доступна нова версія платформи 1С: Підприємство 8.2 (далі Керований додаток), яка повністю змінює весь шар роботи з інтерфейсом. Сюди і командний інтерфейс, і форми, і віконна система. При цьому не тільки змінюється модель розробки інтерфейсу користувача в конфігурації, але і пропонується нова архітектура поділу функціональності між клієнтським додатком і сервером.
Керований додаток підтримує такі типи клієнтів:

  • Товстий клієнт (звичайний та керований режим запуску)
  • Тонкий клієнт
  • Веб-клієнт
У керованому додатку використовуються форми, побудовані нової технології. Вони називаються Керовані форми. Для полегшення переходу попередні форми (т.зв. звичайні форми) також підтримуються, але їх функціональність не розвивається і вони доступні лише в режимі запуску товстого клієнта.
Основні відмінності керованих форм для розробника:
  • Декларативний, а не «за пікселями» опис структури. Конкретне розміщення елементів виконується системою автоматично, коли відображається форма.
  • Вся функціональність форми описується як реквізитіві команд. Реквізити – це дані, з якими працює форма, а команди – дії, що виконуються.
  • Форма виконується і на сервері, і на клієнті.
  • У контексті клієнта недоступні практично всі прикладні типи, і відповідно неможливо змінити дані в інформаційній базі.
  • Для кожного методу або змінної форми обов'язково має бути вказано директива компіляції, визначальна, місце виконання (клієнт або сервер) та доступ до контексту форми.
Перерахуємо директиви компіляції методів форми:
  • &На Клієнті
  • &На сервері
  • &На СерверіБезКонтексту
  • &НаКлієнтіНаСерверіБезКонтексту
Проілюструємо перелічене. На скріншоті приклад керованої форми та її модуля у режимі розробки. Знайдіть декларативний опис, реквізити, директиви компіляції та ін.

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

Позначимо проблему

Пройшло вже кілька років, як нова версія платформи 1С активно використовується і випущено безліч рішень (конфігурацій) як фірмою 1С, так і її численними партнерами.
Чи склалося за цей час у розробників єдине розуміння принципів клієнт-серверної взаємодії при створенні форм і чи змінився підхід до реалізації програмних модулів у нових архітектурних реаліях?

Розглянемо структуру коду (модуль форми) у кількох формах однієї типової конфігурації та спробуємо визначити закономірності.
Під структурою розумітимемо секції коду (найчастіше це блоки коментарів) виділені розробником для групування методів та директиви компіляції цих методів.
Приклад 1:
Секція обробників подій Метод - наклієнт Метод - насервер Метод - наклієнт Секція службових процедур та функцій Допоміжні функції управління введенням
Приклад 2:
Службові процедури та функції Документи оплати Цінності Обробники подій
Приклад 3:
Службові процедури на сервері Службові процедури на клієнті Службові процедури на сервері без контексту Обробники подій шапки Обробники подій команд
Приклад 4:
Процедури загального призначення Обробники подій форми Процедури підсистеми «контактна інформація»
По суті, структура коду відсутня, або, м'якше кажучи, вона аналогічна тому, що було у формах 8.1:

  • Неінформативні слова "Загальні, Службові, Допоміжні".
  • Неробкі спроби розділити клієнтські та серверні методи.
  • Часто методи групуються за інтерфейсними елементами "Робота з табличною частиною Товари, Контактною інформацією".
  • Довільне розташування методів та груп коду. Наприклад, обробники подій можуть бути в одній формі вгорі, в іншій внизу, в третій взагалі не виділені і т.д.
  • І не забуватимемо, що це все в рамках однієї конфігурації.
  • Так бувають конфігурації, в яких слова «Загальні, Службові, Допоміжні» завжди знаходяться на одних і тих же місцях, але…
Навіщо потрібна структура коду?
  • Спрощення супроводу.
  • Спрощення навчання.
  • Фіксація загальних/важливих/вдалих принципів.
  • …ваш варіант
Чому існуючий стандарт розробки фірми 1С не допомагає?
Подивимося опубліковані на дисках ІТС та в різних «Посібниках розробника…» принципи, що рекомендуються при написанні керованої форми.
  • Мінімізуйте кількість серверних дзвінків.
  • Максимум обчислень на сервері.
  • Неконтекстні виклики сервера швидше за контекстні.
  • Програмуйте з урахуванням клієнт-серверної взаємодії.
  • і т.п.
Це гасла, абсолютно вірні, але як їх реалізувати? Як мінімізувати кількість дзвінків, що означає програмувати у клієнт-серверному режимі?

Шаблони проектування чи мудрість поколінь

Клієнт-серверна взаємодія використовується у різних програмних технологіях не один десяток років. Відповідь на зазначені у попередньому розділі питання давно відома та підсумовована у двох базових принципах.
  • Remote Facade(далі Інтерфейс віддаленого доступу)
  • Data Transfer Object(далі Об'єкт перенесення даних)
Слово Мартіну Фаулеру, його опис даних принципів:
  • … кожен об'єкт, потенційно призначений для віддаленого доступу, повинен мати інтерфейс з низьким ступенем деталізації, що дозволить максимально зменшити кількість дзвінків, необхідних для виконання певної процедури. … Замість того, щоб запитувати рахунок та всі його пункти окремо, треба рахувати та оновити всі пункти рахунку за одне звернення. Це впливає на всю структуру об'єкта. Запам'ятайте: інтерфейс віддаленого доступу не містить логіки домену.
  • …якби я був дбайливою мамою, то обов'язково сказав би своїй дитині: «Ніколи не пиши об'єкти перенесення даних!» У більшості випадків об'єкти перенесення даних є не більш ніж роздутий набір полів… Цінність цього огидного монстра полягає виключно у можливості передавати по мережі кілька елементів інформації за один дзвінок- Прийом, який має велике значення для розподілених систем.
Приклади шаблонів у платформі 1С
Прикладний програмний інтерфейс доступний розробнику при розробці керованої форми містить багато прикладів даних принципів.
Наприклад, метод ВідкритиФорму(), типовий «огрублений» інтерфейс.
ПараметриВідкриття = Новий Структура("Параметр1, Параметр2, Параметр3", Значение1, Значение2, Значение3); Форма = Відкрити Форму (Ім'я Форми, Параметри Відкриття);
Порівняйте з прийнятим у v8.1 стилем.
Форма = ОтриматиФорму(Ім'яФорми); Форма.Параметр1 = Значення1; Форма.Параметр2 = Значення2; Форма.Відкрити();

У контексті керованої форми безліч "Об'єктів перенесення даних". Можна виділити системніі обумовлені розробником.
Системні моделюють на клієнті прикладний об'єкт у вигляді одного або декількох елементів даних форми. Створити їх поза прив'язкою до реквізитів форми не можна.

  • ДаніФормиСтруктура
  • ДаніФормиКолекція
  • ДаніФормиСтруктураСколекцією
  • ДаніФормиДерево
Перетворення системних об'єктів перенесення даних на прикладні типи і назад виконується методами:
  • ЗначенняДаніФорми()
  • ДаніФормиЗначення()
  • КопіюватиДаніФорми()
  • ЗначенняВРеквізитФорми()
  • РеквізитФормиЗначення()
Часто явне перетворення використовується для адаптації існуючого рішення. Методи можуть очікувати (використовувати особливості) вхідні параметри, наприклад ТаблицяЗначень, а не ДаніФормиКолекція, або метод був визначений у контексті прикладного об'єкта і став недоступним для прямого виклику з форми.
Приклад 1С v8.1:
// на клієнта в контексті форми ЗаповнитиКеш Користувачів(Підрозділ Посилання)
Приклад 1С v8.2:
// на сервері в контексті форми Обробка Об'єкт = Реквізит ФормиЗначення ("Об'єкт"); ОбробкаОб'єкт.ЗаповнитиКешКористувачів(Підрозділ Посилання); ЗначенняВРеквізитФорми(ОбробкаОб'єкт, "Об'єкт");

Об'єкти перенесення даних, структура яких визначається розробником це невелике підмножина типів доступних і клієнта, і на сервері. Найчастіше як параметри і результати методів «огрубленого» інтерфейсу використовуються:

  • Примітивні типи (рядок, число, булева)
  • Структура
  • Відповідність
  • Масив
  • Посилання на прикладні об'єкти (унікальний ідентифікатор та текстове подання)
Приклад: метод приймає список замовлень зміни статусу і повертає клієнту опис помилок.
&НаСерверіБезКонтексту Функція СерверЗмінитиСтатусЗамовлень(Замовлення, НовийСтатус) Помилки = Новий Відповідність(); // [замовлення][опис помилки] Для Кожного Замовлення Із Замовлення Цикл ПочатиТранзакцію(); Спроба ДокОб = Замовлення. Отримати Об'єкт (); …. інші дії, можливо не тільки із замовленням… Виняток Скасувати транзакцію(); Помилки.Вставити(Замовлення, ОписПомилки()); КінецьСпроби; КінецьЦикл; Повернення Помилки; КінецьФункції // СерверЗмінитиСтатусЗамовлень()

Структуруємо код

Головні цілі, які має відображати модуль керованої форми та підходи до вирішення.
  • Чіткий поділ клієнтського та серверного коду.Не забуватимемо, в момент виконання це два взаємодіючі процеси, у кожному з яких суттєво відрізняється доступний функціонал.
  • Чітке виділення інтерфейсу віддаленого доступу, які методи сервера можна викликати з клієнта, а які не можна? Назви методів віддаленого інтерфейсу починаються з префіксу Сервер. Це дозволяє читати код відразу бачити перехід управління на сервер, і спрощує використання контекстної підказки. Зазначимо, що офіційна рекомендація (ІТС) пропонує називати методи з постфіксами, наприклад, так ЗмінитиСтатусЗамовленьНа Сервері(). Однак повторимо не всі серверні методи можна викликати з клієнта, і тому важливіша логічна доступність, а не місце компіляції. Тому префіксом «Сервер» відзначаємо лише методи доступні для клієнта, метод-приклад назвемо СерверЗмінитиСтатусЗамовлень().
  • Зручність.Справа смаку, приймаємо порядок, коли модуль починається з процедур створення форми на сервері та методів віддаленого доступу.
  • Супроводжуваність.Повинне бути однозначно визначено місце додавання нового коду. Важливий момент, автоматично створювані конфігуратором заготовки методів додаються до кінця модуля. Оскільки найчастіше автоматично створюються обробники подій елементів форми, то відповідний блок розташований останнім, щоб не перетягувати кожен оброблювач в інше місце модуля.
Нижче наведена базова структура модуля, що реалізує цілі.
  • Графічний варіант – наочно показує основний потік виконання.
  • Текстовий варіант - це приклад оформлення шаблону для швидкої вставки структури новий модуль форми.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор=""Дата=""/> // <Описание> // // //////////////////////////////////////////////////// ////////////////////////////// // ЗМІННІ МОДУЛЯ ///////////////// //////////////////////////////////////////////////// /////////////// // НА СЕРВЕРІ //******* ПОДІЇ НА СЕРВЕРІ ******* &НаСервері Процедура ПриСтворенніНаСервері(Відмова, СтандартнаОбробка) //Вставити вміст обробника КінецьПроцедури //******* ІНТЕРФЕЙС ВІДДАЛЕНОГО ДОСТУПУ ******* //******* БІЗНЕС-ЛОГІКА НА СЕРВЕРІ ******* ///////// //////////////////////////////////////////////////// ////////////////////// // ЗАГАЛЬНІ МЕТОДИ КЛІЄНТА І СЕРВЕРУ /////////////////////// //////////////////////////////////////////////////// //////// // НА КЛІЄНТІ //******* БІЗНЕС-ЛОГІКА НА КЛІЄНТІ ******* //******* КОМАНДИ ******* //******* ПОДІЇ НА КЛІЄНТІ ******* /////////////////////////////// //////////////////////////////////////////////////// / ОПЕРАТОРИ ОСНОВНОЇ ПРОГРАМИ

Пов'язані питання
На закінчення позначимо кілька напрямів, про які корисно подумати під час програмування клієнт-серверної взаємодії.
  • Варіанти реалізації інтерфейсу віддаленого доступу. Асинхронність, ступінь деталізації.
  • Кешування.В 1С прийняли невдале архітектурне рішення, ввівши кешування лише на рівні виклику методів загальних модулів і не надавши можливості керування (час актуальності, скидання на вимогу).
  • Неявні серверні дзвінки. Не забувайте про технологічні особливості, багато «нешкідливих» операцій на клієнті провокують платформу на звернення до сервера.


Подібні публікації