Керовані форми уф 1с опис. СтавАналіт

Ми всі знаємо, що компанія "1С" мала багато різних версій платформи 1С, нас зараз цікавитимуть одні з останніх версій на момент написання цієї статті, це версії 1С 8.2 і 1С 8.3. Якщо Вам доводилося працювати в обох цих версіях, то Ви, швидше за все, помітили різницю в інтерфейсах даних версій, для користувачів вони відрізняються лише зовні. По суті, вибір звичайної або керованої програмикаже системі, які форми для відображення потрібно запускати, звичайні або керовані, а також який клієнт програми буде використовуватися за замовчуванням, товстий або тонкий. Більш детальну інформацію про клієнтів читайте у статті «Що таке товстий і тонкий клієнт у 1С, а також їх відмінності».

Звичайний додаток 1С (звичайні форми, звичайний інтерфейс, версія 1С 8.2)

У 1С 8.2 можлива робота тільки із звичайними формами, у режимі звичайного додатку. На зображенні нижче показано базу в режимі роботи "звичайний додаток 1С" (звичайні форми).

Керований додаток 1С (керовані форми, керований інтерфейс, версія 1С 8.3)

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

Чим відрізняються звичайне та кероване додаток 1С?

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

З появою платформи 1С Підприємство 8.2 механізм розробки інтерфейсу користувача значно змінився. З'явилася можливість створення керованих форм та додатків (Малюнок 1).

Малюнок 1

Крім цього пропонується нова система поділу функціональності між клієнтським додатком та сервером.
Керований додаток підтримує такі типи клієнтів:

  • Товстий клієнт (звичайний та керований режим запуску),
  • Тонкий клієнт,
  • Веб-клієнт.

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

  • &На Клієнті,
  • &На Сервері,
  • &На СерверіБезКонтексту,
  • &НаКлієнтіНаСерверіБезКонтексту.

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

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

Функціонування керованих форм має такі відмінні риси (Малюнок 2):

  • Форма існує і клієнта і сервері.

Вона здійснює клієнт-серверну взаємодію (передачу даних та оформлювальних властивостей елементів).

  • Форма не працює з прикладними об'єктами


Малюнок 2

У формі використовуються спеціальні універсальні об'єкти
ДаніФорми(Малюнок 3).


Малюнок 3

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

  • Об'єкт зчитується з бази даних,
  • Об'єкт конвертується в дані форми,
  • Об'єкт видаляється (з пам'яті),
  • Ці форми передаються на клієнта.

Під час запису:

  • Дані форми виходять із клієнта,
  • Дані форми конвертуються в об'єкт,
  • Об'єкт записується в базу даних,
  • Об'єкт видаляється (з пам'яті).

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

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

Звичайні (некеровані) форми можуть працювати лише у товстому клієнті. Тонкий та веб-клієнти підтримують роботу тільки з керованими формами.

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

Найпростіше запустити товстого клієнта в режимі керованого додатка з конфігуратора, вказавши це в параметрах: Сервіс - Параметри - Запуск 1С: Підприємства - Основні - Товстий клієнт (керований додаток).

При цьому слід пам'ятати, що запуск клієнтів у керованому режимі можливий лише в тому випадку, якщо конфігурація вимкнена сумісність у версії 8.1 (властивість Режим Сумісності).

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

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

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

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

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

Головна проблема, що за 10-15 років вже наколбашено дуже багато коду під звичайні форми. Переписувати це все на клієнт-сервер ніхто не хоче навчено роботі з інтерфейсом дуже багато народу. Обов'язковий перехід на БП 3.0 з наступного року породжує паніку в умах розробників та бухгалтерів. Фідбек буде дуже неприємний. До того ж підвищується планка входу в професію, програмувати складніше, типові складніші стали. Чого вартий новий алгоритм проведення у типових документах. УФ чудово виглядають коли у вас 2-3 кнопочки на документах, УФ супер для роботи на мобільних пристроях, але користуються цим 0.01% компаній. Переходити доведеться, якщо 1С не придумає чогось нового, але це буде довго і болісно для всіх. А гроші платити доведеться самим компаніям.

Я теж поки що негатив відчуваю від керованих форм, ось ще мінуси нововведення:

  • нічого? ну я кілька разів зіткнувся, наприклад написати і причепити до конфе ЗУП внеш.печ.форму, обробку там ціла епопея, повно інструкцій в інеті і сторінки коду повинні.
    на товстому клієнта одна процедура із параметрами тобто. розробка хвилинну справу.
    і гальма в тонкому неозброєному видно
  • Щодо вміти готувати керовані форми — це мистецтво заради мистецтва, а який практичний зміст, особливо для файлової версії?
  • я 3 роки спрацював в УФ, але тепер перейшов назад на прості форми, і повірте мені цей перехід психологічно було зробити досить складно, але це мій усвідомлений вибір, бо те, що 1с пропонує на УФ - це абсолютно УГ. може через пару років 1с і зробить прорив, але зараз вона тільки в пошуку того місця, де цей прорив робити.
  • УФ в конфігураторі відкриваються набагато довше.
    Після цього відкриття форм у 8.1 – як на літак пересісти з вантажівки!
  • Гемороя стало більше для всіх, користувачі в шоці від нового інтерфейсу (не всі зізнаються, але туплять значно більше і по менших дрібницях), половина програмістів стало професійними не придатними, знайти роботу середньому фахівцю стало важче та й як видавати якісний продукт. А найприкольніша маркетингова тема УФ у тому скрізь парять що перехід відбувається простим оновленням, тільки щось усі забувають що з початку треба конфу до останніх релізів наздогнати! Але в принципі мені подобається задум!
  • Незнаю моя практика показує протилежне. Там де бухи в стрих формах б'ють вже кілька років на автоматі, в нових УФ типових щомісяця починається «пля, куди тепер 1С після оновлення справи цю кнопку і чому тепер це не працює», що погодитеся не додає швидкість.
  • — коду побільшало
    - код став складнішим
    — доробка типових — значно складніше
    - Користувачі яким я давав УТ11 ніяких переваг у порівнянні з 10.х не знайшли
    - Зате знайшли гальма і недолік деяких функцій типу пошуку (чомусь хотіли саме пошук з вперед-назад а не відбір)
    моя думка — надто великі жертви заради веб-клієнта та планшетиків. Причому особисто я поки що реальної роботи з веб-клієнтом не зустрічав взагалі, кому треба успішно користуватися віддаленим доступом.
  • Клієнт-серверний бедлам повинен бути дати приріст продуктивності та масштабованість, при цьому у витратах – збільшення кодування.
    Однак приріст виявився не у всіх, звідси й розчарування. А на витрати кодування пригнули при цьому всіх.
    P.S. Власне мені керовані подобаються, спокійно на них малюю. Але типові стали химерні.
  • На домашньому (нормальний комп'ютер) веду свою бухію з ІП.
    8.3, БП3, у шашечках. Основне враження — я не працюю, а весь час чекаю. відгук геморойський. ОСВ за рахунком формується проста офігеть - таке враження, що картка рахунку за рік у мегахолдингу.
  • УТ11 - дике гальмо, жах і взагалі кошмар.
    УТ10 літає проти УТ11.
    З приводу УФ — баги роками кишать, все криве, колонки ніколи не поміщаються на одному екрані, розтяг у багатьох випадках жахливий.
    І ще можу мінусів нашліпати дофіга, з плюсів, напевно, нічого не скажу. Їх просто немає.
    Фірми безпосередньо потрапили з цими формами, тому що технологія коштує дорожче, співу як не було так і немає нормальних.

Плюсів мало, але вони звичайно є.

Плюси:

відповідь давно є, чого дали УП:

крос платформність клієнта

  • робота на поганих лініях зв'язку
  • можливість роботи через браузер (без встановлення клієнта)

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С прийняли невдале архітектурне рішення, ввівши кешування лише на рівні виклику методів загальних модулів і не надавши можливості керування (час актуальності, скидання на вимогу).
  • Неявні серверні дзвінки. Не забувайте про технологічні особливості, багато «нешкідливих» операцій на клієнті провокують платформу на звернення до сервера.


 

Можливо, буде корисно почитати: