() kote,
Присоединяюсь к вопросу а так же к вопросам (144),(145),(194),(224)
Предыстория вопроса (введение).
У нас управляемые формы но абсолютно не управляемый код.
За последнее несколько лет сама платформа и методы работы подтянулись к современным требованиям, но конфигуратор остался на уровне 8.0, разве что переход от 8.2 к 8.3 показал что теперь подумали и о разработчиках, хотелось бы что бы в этом направлении работа продолжалась.
На мой взгляд платформа, лучшая в своем роде, и развивается очень динамично. Такое впечатление что команда разработчиков платфомы состоит из молодых увлеченных людей которым интересно развивать продукт, а конфигуратор пишет старая гвардия которой уже все это давно надоело... Вот такое впечатление.
Пока я разрабатывал учетные системы особых проблем не возникало, на 90% хватало готовых объектов Справочники/Документы/Регистры, в общих модулях общие алгоритмы проведения, в общем все красиво, но на данный момент платформа позволяет разрабатывать решения далекие от бухгалтерии, в первую очередь это ERP и системы документооборота с задачами, бизнес процессами, множеством различных "объектов" реального мира, приходится сталкиваться с тем что хотелось бы описать объект/сущность и методы/свойства что бы они были связаны, причем об ООП речи не идет, просто хотя бы организовать код.
Та же подсистема БизнесПроцессов на мой взгляд требует большей проработки, она должна быть "более управляема" из программного кода, в идеале должна быть возможность изменять БП из клиентского приложения(но это уже тянет на 9.0).
Сейчас, на мой взгляд "1С конфигуратор" это инструмент, но не помощник, работая в 1С я должен
ПОМНИТЬ
(я уже делал упор на ПОМНИТЬ, ЗНАТЬ, и еще не раз сделаю, работая в той же IntelliJ IDEA что либо помнить нужно гораздо меньше, в основном упор на понимать) огромное количество вещей.
Так вот, я не могу просто узнать какие функции работают с этой ссылкой, пример: получение полного почтового адреса для КИ, я должен помнить что в таком то модуле лежит такая то функция которая умеет это делать, при этом этих модулей(работающих с КИ) 6 штук.
Теперь собственно вопросы:
Есть ли шанс что вы реализуете что то из списка ниже:
1. Ввести типизацию переменных на уровне IDE (Конфигуратора).
т.е. что бы можно было объявлять типы переменных в коде, и СП умел пользоваться этой информацией, причем на ход выполнения программы эти типы влиять не должны.
Сейчас такая ситуация, у меня 240 справочников если где то использую переменную например ССылкаТрубопроводы мне нужно помнить что в этом справочнике есть реквизит "РабочийДиаметр", потому как СП мне тут совершенно не поможет, все понимают что помнить все это не реально, и обычно начинают искать справочник в дереве метаданных, и хорошо если сейчас отбор по подсистеме стоит на той в которой этот справочник есть, иначе придется еще и отбор сбрасывать, а если до этого он стоял на 6 подсистемах... ну вы понимаете.
2. Ввести типизацию параметров процедур и функций(для функций еще и результат), сейчас типы мы описываем в комментариях к процедуре/функции, при этом СП это никак не помогает да и все типы приходится набирать руками.
3. Использовать типизацию из п.2 при синтаксис контроле (т.е. если определен тип параметра и СП видит что функции передается переменная другого типа, компилятор предупреждает), но если мы предупреждение проигнорировали то код должен работать как обычно). т.е. еще раз обращаю внимание что типизация для СП а не для интерпретатора (я бы конечно хотел и для него но это не реально сделать).
4. Добавить возможность, указывать для процедур и функций в ОбщихМодулях для каких типов они доступны, по аналогии с общими командами, так что бы СП после точки предлагал эти функции, само собой в эти функции неявно должен передаваться "ЭтаССылка", при этом в остальных случаях эти функции недоступны.
5. Реализовать "МодульССылки" по аналогии с модулем объекта, функции этого модуля должны быть доступны для ссылки, в модуле должна быть доступна "ЭтаССылка". Пример вызова ОбъектССылка.ПолучитьНастройки() вместо: омУправлениеНастройками.ПолучитьНастройки(ОбъектССылка). Отличие от п.4 что в этом модуле будет код который работает исключительно с этим объектом, т.е. любая экспортная функция в этом модуле доступна только для ссылки на этот объект.
6. Реализовать "МодульРегистра" в этом модуле можно определять Процедуры/Функции как клиентские так и серверные, для Процедур/Функций добавить возможность указания типа для которого данная процедура/функция доступна, если тип указан то процедуре доступна ЭтаССылка. Такие процедуры можно вызывать только через ОбъектССылка.ИмяПроцедуры
Пример использования:
Дано:
РегистрСведений.НастройкиОбъектов
Измерение "Объект" составной тип определенный в конфигураторе (8.3) = "ТипыХраненияНастроекОбъектов"
В него входят 3 справочника: Пользователи, Контрагенты, Организации.
В модуле регистра определена функция:
&НаСервере
Функция ПолучитьНастройки() Экспорт (Тип("ТипыХраненияНастроекОбъектов"))
//Код получения, доступна переменная ЭтаССылка
КонецФункции
В любо месте мы можем написать ПользователиССылка.ПолучитьНастройки(),КонтрагентыССылка.ПолучитьНастройки()
Выгода:
1. Нам не нужно заводить специальный ОМ.
2. Код работающий с регистром хранится вместе с регистром.
3. Нам не нужно помнить о этом методе, СП нам сам подскажет что для этой ссылки доступно такое действие.
4. Если у нас появится новый объект, нам достаточно изменить состав составного типа: "ТипыХраненияНастроекОбъектов"
p.s. я знаю про модуль менеджера, но у него другие задачи, с которыми он справляется хорошо.
Этот пункт похож на п.4. отличие в том что в нем удобно хранить код который работает исключительно с данными этого регистра, пусть и для разных объектов. В то время как в ОМ будет общий код который затрагивает много различных объектов и вызывается для многих объектов.
Дополнительно пожелания:
1. Нет никаких средств по организации метаданных, как пример те же папки в дереве метаданных были бы не лишними, возможно еще какие то варианты огранизации кода. Потому как
УправлениеКонтактнойИнформацией
УправлениеКонтактнойИнформациейКлассификаторы
УправлениеКонтактнойИнформациейКлассификаторыКлиент
УправлениеКонтактнойИнформациейКлиент
УправлениеКонтактнойИнформациейПереопределяемый
УправлениеКонтактнойИнформациейСобытия
Это конечно хорошо, но когда у тебя есть ОМ УправлениеПроцессами вызов функций из этого модуля удовольствие на любителя (да и поиск этого модуля среди 400 тоже).
При этом у меня например 400 общих модулей и все они идут сплошным списком, фильтр по подсистемам конечно немного помогает, но часто его отключать приходится.
2. Нет возможности даже добавлять нормальное описание для разработчика к объектам метаданных, все что у нас есть это однострочный комментарий. В итоге описание метаданных хранится в EXCEL.
3. При выделении переменной она не подсвечивается по всему коду, было бы удобно.
Еще можно было бы поговорить о SQl view, мне довелось работать с решениями написанными на MS SQL и для меня остается загадкой почему такой мощный механизм или его аналог не доступен в 1С, у каждого есть в конфигурации запросы которые используются во многих местах и отчетах, если с дин. списками еще как то можно программно везде этот текст запроса устанавливать, то с тем же CСКД приходится вести "БИБИЛИОТЕКУ" типовых запросов и везде копировать его, при этом если такой запрос нужно немного изменить то понятно к чему это приводит. В то же время один раз создав View можно было бы использовать его во многих местах.
Я понимаю почему нельзя использовать UPDATE, объектная система и все такое, но подобные вещи на мой взгляд вполне можно реализовать.
Я думаю список можно дополнять отвечая на мое сообещние(так можно будет собрать все пожелания по конфигуратору), если есть шанс что хоть 10% из этого списка исправят это уже облегчит нам жизнь.
