1с керований інтерфейс. Область системних команд

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

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

Швидше за все, це здивує користувачів програми 1С Бухгалтерія 8 редакція 2.0. Адже у ній є такі інтерфейси.

  • Бухгалтерський.
  • ПДФО підприємця.
  • Адміністративний.
  • Повний.

Це так. Ну і що? Що нам давали ці інтерфейси? Припустимо, у бухгалтерії є окрім головного бухгалтера ще два бухгалтери. Один займається лише банківськими та касовими операціями, а інший веде облік основних засобів. І тут треба було запрошувати програміста, щоб він розробив спеціалізовані інтерфейси кожного з цих користувачів. Тільки фахівець, який добре знає конфігурацію, може створити і грамотно описати нові ролі та права. Очевидно, такі зміни можливі лише при знятті конфігурації з підтримки.

Навпаки, у програмі 1С Бухгалтерія 8 ред. 3.0 користувач може самостійно або за допомогою більш підготовленого колеги сформувати потрібний для своєї роботи командний інтерфейс. Давайте на деяких прикладах розглянемо, як це робиться.

1. Командний інтерфейс це керований інтерфейс 1С

Командний інтерфейс у програмі 1С Бухгалтерія 8 ред. 3.0 є керованим інтерфейсом. Це означає, що користувач може самостійно керувати ним безпосередньо у режимі 1С Підприємство. Так, саме користувач, а не лише програміст у режимі Конфігуратор.

Для цього на панелі системних команд у головному меню є пункт «Вид», який відкриває доступ до команд редагування панелей керованого інтерфейсу.


Пояснення вимагають лише дві команди.

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

2. Створити інтерфейс для розрахунка

Створення та налаштування інтерфейсу розглянемо на простому прикладі. Припустимо, що нашому користувачеві потрібні для роботи лише два розділи: «Банк та каса» та «Співробітники та зарплата». Видалити непотрібні розділи можна у формі, яка викликається за командою «ІНФОРМАЦІЙНА ПАНЕЛЬ \ Головне меню \ Вид \ Налаштування панелі розділів».


За допомогою кнопки "Видалити" видаліть не потрібні нашому користувачеві розділи. Залишіть лише «Банк та каса» та «Співробітники та зарплата». Після збереження змін (кнопка ОК) отримаємо такий вигляд інтерфейсу.


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


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

3. Налаштувати інтерфейс для касира

Налаштуємо інтерфейс для касира, який займається лише касовими операціями. Вважатимемо, що адміністратор вже створив користувача «Касир» і надав йому відповідні права.

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

За будь-якого нового запуску програми вона завжди автоматично відкривається на розділі «Робочий стіл».

Можна повністю вимкнути режим відображення панелі розділів або залишити лише один розділ, наприклад, «Банк і каса». Або ви могли завершити роботу, наприклад, у розділі «Покупки та продажі». Неважливо. За будь-якого нового запуску програми завжди актуалізується «Робочий стіл». Його видалити неможливо.

Таким чином, якщо нам потрібний лише один розділ бухгалтерського обліку, наприклад, «Банк і каса», то відобразити його на панелі розділів не вийде. Разом з ним відображатиметься і розділ «Робочий стіл». У нашому випадку це показ не потрібних касиру посилань.

Вчинимо наступним чином. Активуйте «Робочий стіл». Зверніть увагу, що на його навігаційній панелі є командне посилання «Касові документи». Відредагуємо панелі навігації та дій для розділу «Робочий стіл».


Для редагування панелі навігації виконайте команду "ІНФОРМАЦІЙНА ПАНЕЛЬ \ Головне меню \ Вигляд \ Налаштування панелі навігації".


Маніпулюючи кнопками «Додати», «Додати все», «Видалити» та «Видалити все», залиште у правому вікні лише навігаційну команду «Касові документи».


Відредагуємо панель дій розділу робочий стіл. Для цього виконайте команду "ІНФОРМАЦІЙНА ПАНЕЛЬ \ Головне меню \ Вид \ Налаштування панелі дій".


Маніпулюючи кнопками «Додати», «Додати все», «Видалити» та «Видалити все», залиште у правому вікні лише команди, окреслені червоними прямокутниками.

Ми припустили, що наша організація не займається роздрібним продажем. Тому документ «Звіт про роздрібні продажі» касиру не потрібен. Ми також припустили, що касиру не потрібні стандартні бухгалтерські звіти. Тому ми їх також вилучили з панелі дій.

За командою "ІНФОРМАЦІЙНА ПАНЕЛЬ \ Головне меню \ Вигляд \ Панель розділів" відключіть відображення панелі розділів. Завершіть роботу з програмою та знову відкрийте її від імені касира. Ось так виглядатиме його інтерфейс.


Нічого зайвого! Тільки необхідні касиру документи та два звіти. При необхідності список касових документів він може відкрити, натиснувши на навігаційну команду «Касові документи». Вона розташована на панелі навігації.

4. Інтерфейс програми 1С Бухгалтерія 7.7

Розробники 1С чудово розуміють, що, як би хороший не був новий інтерфейс, але багато хто з нас живе за принципом: найкраще – ворог хорошого. Так за переході з програми 1С Бухгалтерія 7.7 часто можна почути. Я нічого не розумію в новому інтерфейсі, мені ніколи розбиратися з ним, у мене термінова робота.

Такі користувачі в кілька кліків можуть встановити у собі в програмі 1С: Бухгалтерія 8 ред. 3.0 так вподобаний ним сімковий інтерфейс. Виглядає він, як показано малюнку.


Зовні він, звичайно, відрізняється від оригінального сімкового інтерфейсу. Але структурно все те саме.

Увімкнути сімковий інтерфейс можна лише в тому випадку, якщо у програмі для відкриття форм об'єктів встановлено режим «В закладках». Він встановлюється у формі «Параметри», яка викликається за командою «Панель системних команд Головне меню Сервіс Параметри».


Потім на панелі розділів активізуйте розділ «Адміністрація» та клацніть на панелі дій за посиланням «Налаштування програми».


У формі «Налаштування програми», що відкрилася в робочій області, перейдіть на закладку «Інтерфейс» і активізуйте радіо кнопку «Інтерфейс, аналогічний 1С:Бухгалтерія 7.7».


Всі. Збережіть результат, натиснувши кнопку ОК. Працюйте зі звичним вам семирічним інтерфейсом. У той же час не забувайте в демонстраційній базі знаходити час, щоб освоїти оригінальний інтерфейс. Коли ви звикнете до рідного інтерфейсу програми 1С:Бухгалтерія 8 ред. 3.0 то дуже швидко можете його відновити.

Для цього на панелі розділів клацніть посилання «Сервіс». На панелі навігації клацніть посилання «Налаштування програми». Активізуйте закладку «Інтерфейс» та вкажіть «Стандартний інтерфейс 1С:Бухгалтерія 8». Ну і, звісно, ​​ОК.

6. Управління формами об'єктів

Програма 1С Бухгалтерія 8 ред. 3.0 надає користувачеві як можливість управління командним інтерфейсом. У ньому можна керувати і формами окремих об'єктів. Це форми журналів (списків) документів, форми самих документів та довідники. Для керування цими формами у правому верхньому кутку відкритої у робочій області форми є кнопка «Всі дії». А в ній команда "Змінити форму".

Звичайно, програміст має більше можливостей при створенні форм об'єктів. І все ж давайте розглянемо один простий приклад.

Спочатку форма документа «Рахунок на оплату покупцям» виглядає так, як показано на малюнку.


А тепер припустимо, що наша організація займається лише наданням послуг. Отже, реквізити «Склад» та «Адреса доставки» нам не потрібні. У табличній частині нам також не потрібні закладки «Товари» та «Зворотна номенклатура». Щоб позбутися їх, натисніть кнопку «Всі дії» та виберіть пункт «Змінити форму».


Якщо потрібна нам гілка не розкрита, то клацніть по хрестику. Він у кухлі ліворуч від гілки. Потім зніміть прапори з тих реквізитів та сторінок, які нам не потрібні.

Так само можна видозмінити і командну панель форми документи. Давайте зробимо такі зміни. Насамперед розкрийте гілку «Командна панель».

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

Зрештою отримаємо таку форму для документа «Рахунок на оплату покупцю».


Для обережних користувачів хочеться відзначити таке.

Увага. Не бійтеся експериментувати з налаштуваннями форм об'єктів. Вони не змінюють обліковий вміст інформаційної бази.

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

Для цього на формі об'єкта виконайте команду "Всі дії \ Змінити форму". Відкриється вже відоме нам «Налаштування форми». У ній виконайте команду "Всі дії \ Встановити стандартні настройки".

7. Інформування про помилки

Програма 1С Бухгалтерія 8 ред. 3.0 контролює наповнення обов'язкових реквізитів. Втім, це робили й попередні редакції. Але, на відміну від попередніх редакцій, діагностичні повідомлення 1С Бухгалтерія 8 редакції 3.0 стали більш інформативними. Вони показують, у якому реквізиті і яка міститься помилка.

Наприклад, користувачі-початківці часто роблять таку помилку. Вони намагаються заповнювати реквізити документів не шляхом підбору із відповідних довідників, а вручну забивають потрібні значення. На малюнку показано, що користувач вручну у реквізиті "Контрагент" вбив ТОВ "Зоря". Такого контрагента Програма 1С Бухгалтерія ред. 2.0 не знайшла у довіднику «Контрагенти». Тому під час запису документа вона повідомила про помилку, як показано малюнку.


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

А от як реагує на таку ж помилку програма 1С Бухгалтерія ред. 3.0.


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

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


Переміщатися від помилки до помилки можна двома способами. Або використовуючи навігаційні стрілки в діагностичному повідомленні, або натиснувши посилання в панелі повідомлень.

Ось, мабуть, і все. Сподіваюся, що керований командний інтерфейс програми Бухгалтерія 1С 8 ред. 3.0 не буде каменем спотикання під час освоєння цієї програми. Він дійсно зручніший, але необхідно витратити трохи свого дорогоцінного часу для його освоєння.

Ми всі знаємо, що компанія "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С: Таксі»

Глава 2.Звичайний і керований додаток 1С

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

Що взагалі таке "інтерфейс"? По суті, це спільна межа між двома системами, що взаємодіють (дуже часто однією системою є людина). Візьмемо, наприклад, автомобіль. Чи має він інтерфейс? Так звичайно. Але що ж є спільним кордоном між автомобілем та людиною? По-перше, це робоче місце, тобто. безпосередньо водійське сидіння та органи управління (кермо, педаль акселератора, педаль гальма тощо). По-друге, це принципи взаємодії людини з автомобілем, які є якимось набором правил. Наприклад, щоб прискорити автомобіль, потрібно натиснути педаль газу, сповільнити – педаль гальма, для повороту направо потрібно викрутити кермо вправо і т.д. Завдяки двом цим сутностям людина може керувати автомобілем. Заберіть щось одне, і керування автомобілем не стане можливим.

У світі програмного забезпечення все так само. Одна система – це людина – оператор, користувач. А друга система - це деякий додаток, створений для автоматизації певного виду людської діяльності (ми розглядаємо прикладне програмування).

Наприклад, нам потрібно самостійно вести складський облік: здійснювати надходження товару на склад, списання цього товару і стежити за залишками. Що ж буде спільним кордоном між додатком, не різниці, як і де написаним, і користувачем? По-перше, це органи введення інформації — інакше як Ви передасте до програми, що на склад надійшло 5 штук якоїсь продукції. У нашому випадку це комп'ютерна клавіатура та комп'ютерна мишка. По-друге, це система взаємодії між комп'ютером та людиною. Наприклад, це може бути інтерфейс командного рядка: Ви будете за допомогою клавіатури вводити різні текстові рядки (команди) і за їх допомогою виконувати потрібні дії (фіксувати прихід товару, витрата товару тощо). Такий інтерфейс виглядає приблизно так: див. 1.2.1.

Мал. 1.2.1 Приклад командного рядка

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

Цей вид інтерфейсу давно є архаїчним, і на його зміну прийшов графічний інтерфейс користувача (англ. graphical user interface GUI). У цьому інтерфейсі взаємодія між користувачем та програмою відбувається за допомогою різних графічних елементів, намальованих на дисплеї (кнопки, іконки, перемикачі тощо). У графічному інтерфейсі оператор має довільний доступ у вигляді органів управління будь-яким графічним елементами. У нашому випадку, коли автоматизуємо складський облік, взаємодія може мати такий вигляд: оператор натискає кнопку «Прихід», відкривається форма підбору товару, де оператор вибирає потрібний товар зі списку та вводить його кількість. Якщо потрібно здійснити витрату, то оператор натискає кнопку «Витрата», так само відкривається форма підбору, де оператор також вибирає потрібний товар і вводить його кількість. Коли потрібно звірити залишки, оператор натискає кнопку «Залишки», і програма виводить йому залишки товару складі. Тим самим за допомогою даного графічного інтерфейсу Ви можете успішно вести облік товарів на складі.

Закінчимо з теоретичною частиною та перейдемо безпосередньо до теми цього розділу. А саме до видів інтерфейсів програми 1С, які всі є графічними інтерфейсами користувача. У програми «1С: Підприємство 8» є два глобальні види графічних інтерфейсів додатків. Це режим звичайної програми та режим програми під керованими формами (або керована програма).

Платформи редакції 8.0 та 8.1. працювали лише під звичайним режимом, більш високі версії платформи (8.2, 8.3 і т.д.) можуть працювати і в режимі звичайної програми, і в режимі керованого додатка.

Режим звичайної програми

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

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

Подивимося коротко, як виглядає цей режим. Багатьом він уже буде знайомий, але деякі, особливо ті, хто не застав роботу під платформами 8.0 та 8.1, його побачать уперше.

Після завантаження програми користувач бачить інтерфейс з меню у верхній частині (див. рис. 1.2.2).

Рис 1.2.2 Вигляд інтерфейсу звичайної програми

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

Рис.1.2.3. Форма списку документів

З форми списку користувач може відкрити форму документа чи довідника (див. рис. 1.2.4).

Мал. 1.2.4. Форма документа

Розробник може використовувати автоматично генеровані форми, або самостійно конструювати їх у .

Звичайні форми розробнику потрібно конструювати мишкою: розміщувати на формі необхідні елементи (кнопку, поле, таблицю), пересувати їх у зручне місце та визначати розмір (див. рис. 1.2.5).

Рис. 1.2.5. Конструювання традиційних форм

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

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

Режим керованої програми

Тож у чому особливість і кардинальне відмінність режиму керованого докладання від звичайного? Основна відмінність - це використання керованого командного інтерфейсу та керованих форм. Розберемо кожну з цих сутностей окремо. Що таке керований командний інтерфейс? Щоб відповісти на це питання, необхідно заглибитися знову в минуле.

Розглянемо у найпростішому вигляді, як велася розробка конфігурації у звичайному додатку. Спочатку ми конструювали бізнес-логіку: документи, довідники, звіти, обробки та їхню взаємодію між собою. Потім ми налаштовували ролі, наприклад, користувач з роллю «Постачальник» мав доступ до документа «Прихід товару», а до документа «Витрата товару» — ні. І навпаки, користувач за участю «Продавець» мав доступ до документа «Витрата товару», а до документа «Прихід товару» — ні. Наступним кроком ми розробляли інтерфейси кожного виду користувача. Хто практикував розробку під звичайним додатком, пам'ятає, що був такий конфігураційний об'єкт, як «Інтерфейс», в якому можна було налаштувати кожне меню на кшталт меню на малюнку 1.2.2. І в нашому випадку розробнику потрібно було зробити два інтерфейси: один для постачальника, а інший для продавця. Тому що якби він розробив один спільний інтерфейс, в якому можна відкрити і документ «Прихід товару», і документ «Витрата товару», то було б не зовсім правильно, якби постачальник при спробі відкрити список документів «Витрата товару», отримав би повідомлення системи, що він не має цього прав. Щоб уникнути цього, необхідно було зробити два інтерфейси і для кожного користувача вказати, під яким інтерфейсом він має працювати.

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

Мал. 1.2.6. Керований командний інтерфейс

При розробці керованого програми програмісту доведеться йти трохи іншим шляхом. Перш ніж розробляти бізнес-логіку, нам потрібно визначити підсистеми, до яких входитимуть наші об'єкти (у звичайному додатку вони теж є, але мають більше декларативний характер). Наприклад, документ "Прихід товарів" входитиме в підсистему "Постачання", а документ "Витрата товарів" входитиме в підсистему "Продажі". У той же час деякі об'єкти можуть перебувати в кількох підсистемах одночасно: довідник «Товари» входитиме і в підсистему «Продажі», і в підсистему «Постачання», і в підсистему «Маркетинг». У цьому випадку розробнику немає необхідності створювати об'єкт «Інтерфейс», система сама автоматично побудує потрібний вигляд інтерфейсу, виходячи з налаштувань прав користувача та функціональних опцій.

Якщо у якогось користувача буде роль, у якій немає прав на перегляд підсистеми, наприклад «Постачання», то при запуску 1С він просто не побачить цей пункт меню. Також він не побачить у списку меню документ, на який у нього немає права хоча б на перегляд.

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

Мал. 1.2.7. Інтерфейс користувача з обмеженими правами

Ще одна відмінність від звичайного інтерфейсу, що користувач самостійно може визначати вид свого інтерфейсу за допомогою налаштувань навігацій, дій, розділів та ін. та «Товар». Вийде такий вигляд:

Мал. 1.2.8. Інтерфейс користувача з урізаними функціями поточного розділу

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

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

Тепер розберемо, що таке керовані форми.

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

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


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

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

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

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

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

Мені навіть стало шкода, що 1С не відмовилася від звичайних форм через те, що вони використовуються в режимі робочого столу. Адже можна було б дати можливість в УФ точного піксельного позиціонування, і звичайні форми відмерли б з часом. А так доводиться розпорошувати сили ще й на знання старого функціоналу.

А так, звичайно, УФ набагато швидше за звичайні, т.к. працюють за триланковою схемою між клієнтом та сервером.

Крім того, сам функціонал УФ набагато багатший і ширший, ніж у звичайних - не дивно, пройшло багато часу, і в них потрапили багато інтерфейсних знахідок.

Наприклад, виведення динамічної таблиці з угрупованнями або витягування реквізитів об'єктів безпосередньо в динамічний список. Або навіть радіокнопка не як точок, а як тумблерів.

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

Модальності, подійність та блокування інтерфейсу

Я чув, що у 8.3 з'явилася відмова від модальних функцій на кшталтПитання, Попередження, ВідкритиФормуМодально. Для мене було незрозуміло, навіщо це було зроблено.

Яким було моє здивування, як у одному з прикладів викладач викликав відкриття форми з параметром «Заблокувати весь інтерфейс», тобто. насправді модально.

Я був певен, що від модальності відмовилися.

Розуміння прийшло не одразу.

У 1С не відмовилися від модальних вікон. Є нові функції, щоб вивести попередження, поставити питання, відкрити модально діалог вибору файлу.

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

Тобто. платформа 1С позбавилася рудименту заморожування виконання коду і перейшла на повністю подієве управління формами.

Звичайно ж, це жодним чином не пов'язане з тим, що браузери мають труднощі з показом модальних вікон. Це помилка і забобон - забудьте його як поганий сон. Все логічно. По суті тепер виконання повністю подієве та асинхронне, від синхронного виконання вдалося позбутися.

У 1С з'явилися міні-конструктори – рефакторинг. Це спрощує написання обробників оповіщення для асинхронного режиму роботи, щоби не писати їх вручну.

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

Нові можливості інтерфейсу

Меню

Якщо керовані форми виглядають цілком логічним і правильним напрямом розвитку, то напрямок розвитку системи меню для мене так і залишився незрозумілим.
Безперечно, меню, де показується лише один рівень, потім потрібно заходити в наступний рівень і так до вибору потрібного пункту вже морально застаріло, і йому на зміну прийшла карта меню, де розгорнуто відразу кілька пунктів меню. Це було зроблено у типових ще до виходу нових інтерфейсів меню в 8.2.

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

Я так зрозумів, що 1С вважало за неправильне, що прикладний об'єкт Інтерфейс не використовують, і вирішила випустити йому нову, просунуту альтернативу.

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

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

Я запитав викладача: «Мені зрозуміло щодо керованих форм, але навіщо потрібно було розвивати інтерфейси, чому не можна було трохи доопрацювати класичне меню»?

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

Порядок обходу

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

Робоча область та вкладені форми

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

Набагато простіше було б створювати її програмним кодом чи використовувати механізм вкладених форм.

Що так і не реалізовано о 8.2-8.3

Я так і не дочекався вкладених форм. На жаль, їх немає, хоча вони використовувалися ще у стародавньому Access.

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

Функціональні опції та видимість елементів

Свого часу RLSбули створені для того, щоб показувати користувачам лише окремі записи таблиць.

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

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

Свого часу я довів, що RLSзміна поступається програмному контролю записи лише на рівні модуля объекта/подписки. Так само підозрюю, будь-яка функціональна опція поступається звичайному алгоритмічному опису контролю видимості елементів - як і простоті використання, і у універсальності підходу.

Користувач конфігуратора змушений дуже багато думати, як контролювати видимість – ролями чи через функціональні опції. Один раз написавши універсальний алгоритм визначення видимості полів, він міг би застосовувати його завжди без усяких цих платформних милиць.

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

Інтерфейс 8.2 та інтерфейс Таксі

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

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

Незрозуміло, навіщо було йти таким заплутаним шляхом, якщо зрештою базова система меню в 8.1 ще більш економно витрачала робочий простір екрану?

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

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

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

Не опрацьована ідеологія

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

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

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

Сумніви щодо ефективності

Деякі підходи 1С до usabilityвикликають сумніви.

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

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

Можливості збереження налаштувань

Налаштування форми зберігаються безпосередньо в базу, а не в сеансі. При аварійному завершенні вони не губляться. Відповідно, з'явився новий механізм роботи з цими налаштуваннями, де можна зберігати свої дані. АльтернативаЗберегти/ВідновитиЗначення.

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

Інші питання

Що таке керовані форми?

У керованих формах код виконується на клієнті та сервері.

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

А сервер знаходиться у безпосередньому та швидкому з'єднанні з базою даних.

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

Саме так працюють керовані форми. При належній вправності постійне звернення до сервера не складно.

Така організація ефективніше, ніж підключення до сервера через віддалений доступ, ще, робота можлива безпосередньо через браузер, тобто. на будь-якій платформі - Windows, Linux, Android , Mac OS .

Нотатки по 1С розсипом

Тут наведу нотатки, які писав собі, вони містять цінні знання:

  1. У вікні запуску 1С прописуються не інформаційні бази, а точки входу. Тобто. одна база може бути кілька разів, але прописана для різних користувачів та різних інструментів роботи - браузер, тонкий/товстий клієнт, вхід для адміністратора.
  2. Для адміністратора з'явився ключ, який вимикає контроль ролей. Увійти в Підприємство у такий спосіб можна, лише якщо доступні адміністративні права на конфігурацію.
  3. Загальні реквізити - не плутати їх із загальними реквізитами 1С7, 82 вони використовуються для поділу доступу в інтерфейсі.
  4. Часто використовував мінімальну висоту списку у формі, щоб позбутися зайвої смуги прокручування форми.
  5. Не варто зберігати картинки у реквізиті довідника, це призводить до падіння продуктивності довідників, треба використовувати регістр відомостей.
  6. У процедурах сервера під час передачі параметрів потрібно використовувати ЗНАЧ, щоб параметр не передавався назад на сервер.
  7. Нові функціїПочинаєтьсяСі СтрЗакінчуєтьсяНа, Можливо та інші, з платформи 8.3.6.
  8. У 1с 8.2 виник привілейований режим, тобто. можна відключати контроль прав доступу лише на рівні ролей на ділянках коду.
  9. Елементи форми список, таблиця значень та дерево значень відрізняються тим, що список на сервері та клієнті має однакове уявлення, а для таблиці та дерева створюються спеціальні об'єкти та їх треба перетворювати на сервері.
  10. Порадувало, що викладач любить називати об'єкти в однині і називати модулі з підкреслення, щоб ці модулі йшли першим по порядку в контекстній підказці.

Про життя та навколо 1С

Викладач стверджував:

  1. Розробку необхідно вести з інтерфейсу.
    Моя думка : Твердження сумнівне, т.к. знання та досвід використання архітектури платформи дозволяє одразу йти від прикладних об'єктів, а інтерфейс вже будувати потім.
  2. Керівник не вводить дані, лише дивиться звіти. А керує не введенням даних до 1С, а телефоном і через секретаря. Тому керівнику достатньо браузера, а поля введення потрібні лише фільтрації даних.
    Моя думка : Так, це схоже на істину
  3. Критикував БСП (Бібліотека Стандартних Підсистем). У тому плані, що з неї неможливо і дуже важко виділити необхідні модулі.
    Моя думка : Т.к. навіть БСП не вдалося розбити на модулі, те й УПП не виходить розбити на модулі УТ, ЗУП, БП, Виробництво. І тут не платформа винна, а неправильна методологія написання типових - не дотримується модульності. Той же
    Navisionдавно має можливість спочатку продати клієнту бухгалтерію, а потім він може докупити торгівлю, виробництво та зарплату за потреби, без переписування коду та переходу на нову програму.
  4. Типові стали дуже складними, їх важко змінювати. Знову ж таки не через складність платформи, а через неправильну організацію типових. При цьому губиться основний принцип - швидке та економне супроводження та доопрацювання типових конфігурацій при необхідності.
  5. Було продемонстровано варіант оформлення замовлення, коли ліворуч у робочій області знаходиться номенклатура, праворуч - список замовлень. Навпаки, номенклатури можна ставити кількість, потім перетягувати її до списку замовлень і формується замовлення. Перевага – не блокується таблиця замовлень для створення нового замовлення.
    Моя думка : Перевага надумана - все ж таки користувачам звичніше бачити відібраний товар у табличній частині, можна зберегти це замовлення як чернетку або скопіювати замовлення із шаблону. Загалом документи придумані не дарма.
  6. Пояснював різницю між розділами «Головне», «Важливе», «Перейти», «Дивися також».
    Моя думка : Особисто я зрозумів неясно, а значить, більшість так і не зрозуміє ці закладені в платформу нюанси.
    usabilityв таксі. Тому інтерфейси будуть виглядати як раніше, як вже звикли і користувачі, і програмісти 1С.
  7. У комірці табличного поля на формі, джерелом якого є довільний запит, не можна вводити дані, як у полі введення. Це зроблено на користь usability, щоб користувач фокусувався на введенні даних в окремому вікні.
    Моя думка : Я навів приклад із введенням у табличні частини, де таке поле є, сенс заборони мені не зрозумілий
  8. Розлучення виникають від порівняння чоловіка з іншими людьми. Менше порівнянь – міцніший за шлюб.
  9. Іноземні мови легше вивчати, коли вивчаєш їх відразу кілька, знімається зашореність і зацикленість однією рідною мовою.
  10. Іноземні мови неможливо вивчати, якщо прив'язувати іноземне слово до слова рідною мовою, потрібно прив'язувати до образу. Ланцюжок іноземне слово - образ коротше ніж ланцюжок іноземне слово - рідне слово - образ. В останньому випадку мислити іноземною не вийде.

Висновок

Висловлюю подяку викладачеві.

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

Тепер керовані форми не лякають мене, а, навпаки, тягнуть за собою пізнати їх.

Сподіваюся, і ви, які читають цю статтю, оціните керовані форми.