OneS
OneS copied to clipboard
SeiOkami
Папки в структуре конфигурации
Такие полотна сложно читать и приходится постоянно прибегать к долгому поиску, но что если дать возможность разбивать их на логические папки.
Это можно отнести к объектам (общие модули, документы, справочники), реквизитам объектов, формам, а так же реквизитам форм.
При этом, такая логика не конфликтует с подсистемами, а лишь дополняет возможностью более понятно расположить элементы системы по папочкам, которые можно "свернуть""развернуть" прямо в дереве, без необходимости включать\отключать фильтры по подсистемам.
А фильтр по подсистемам чем не угодил? Вроде ту же самую функцию выполняет.
А фильтр по подсистемам чем не угодил? Вроде ту же самую функцию выполняет.
Видимо для удобства например кучи бспшных модулей типа общего назначения, работа с файлами, и тд и тп. Не плодить же тут подсистемы.
Не плодить же тут подсистемы.
Ну, на сколько я понимаю, в этом и есть смысл подсистем. Если посмотреть вложенные подсистемы той же БЭД, складывается именно такое ощущение.
А фильтр по подсистемам чем не угодил? Вроде ту же самую функцию выполняет.
каммон, идти и делать отбор намного сложнее, чем просто раскрыть скрыть папку...
А фильтр по подсистемам чем не угодил? Вроде ту же самую функцию выполняет.
Вы же на github посмотрите проекты на других языках, посмотрите их структуру каталогов. Думаю вы поймете чем дерево отличается от списка.
https://github.com/SeiOkami/OneS/issues/17#issuecomment-814009520 Вот про то же самое комментарий
А фильтр по подсистемам чем не угодил? Вроде ту же самую функцию выполняет.
Просто группировка не должна быть целью. Изменение должно повышать эффективность/удобство использования языка или обращение к объектам подсистемы. Если сейчас мы имеем набор модулей
АдресныйКлассификатор
АдресныйКлассификаторВызовСервера
АдресныйКлассификаторКлиент
...
АдресныйКлассификаторПовтИсп
то объединив их в "папку" АдресныйКлассификатор было бы логично и обращение в коде через точку
АдресныйКлассификатор.ВызовСервера.Метод()
АдресныйКлассификатор.ПовтИсп.Метод()
и уже благодаря расширениям или просто изменению конфигурации расширять функциональность такой подсистемы своими модулями
АдресныйКлассификатор.РасширениеВызовСервера.ПолучитьДанныеПоИдентификаторуФИАСДома(гуид)
Когда-то на партнерке уже было предложение добавить набор модулей непосредственно в сам объект таким образом инкапсулировав обращения к нему, но на мое удивление у поста одни минусы.
А фильтр по подсистемам чем не угодил? Вроде ту же самую функцию выполняет.
Просто группировка не должна быть целью. Изменение должно повышать эффективность/удобство использования языка или обращение к объектам подсистемы.
Если сейчас мы имеем набор модулей
АдресныйКлассификатор АдресныйКлассификаторВызовСервера АдресныйКлассификаторКлиент ... АдресныйКлассификаторПовтИспто объединив их в "папку" АдресныйКлассификатор было бы логично и обращение в коде через точку
АдресныйКлассификатор.ВызовСервера.Метод() АдресныйКлассификатор.ПовтИсп.Метод()и уже благодаря расширениям или просто изменению конфигурации расширять функциональность такой подсистемы своими модулями
АдресныйКлассификатор.РасширениеВызовСервера.ПолучитьДанныеПоИдентификаторуФИАСДома(гуид)Когда-то на партнерке уже было предложение добавить набор модулей непосредственно в сам объект таким образом инкапсулировав обращения к нему, но на мое удивление у поста одни минусы.
Ну это костыль связанный с особенностями настроек общих модулей. Может стоит ещё дополнительно подумать, как избавиться от этих настроек.
Ну это костыль связанный с особенностями настроек общих модулей. Может стоит ещё дополнительно подумать, как избавиться от этих настроек.
возможно, но моей фантазии не хватает чтобы понять как от них избавиться, а главное зачем от них избавляться. Методы повторного использования - отличная вещь. Разделение клиент/сервер/вызовСервера - принципиальная необходимость. Попытки избавиться от них скорее всего будут сводиться к тому что вместо модулей будут использоваться директивы компиляции, а вместо правил именования модулей применение правил именования процедур и функций. Таким образом получим общий модуль - помойку где разработчик пишет все подряд, а поддержка продолжает страдать.
Как по мне, идеал - вообще не использовать общие модули. Любой модуль/форма/макет должен относиться к конкретному объекту. Что будет являться этим объектом - подсистема/обработка/справочник/регистр или некая абстрактная новая сущность "папка" уже менее важно.
Отправлено в чат: https://t.me/e1c_community/58477 Отправлено боту 1С в 09:33
Папки - условно статично, глобально для всех разработчиков, надо изменять конфигурацию. Если и делать так, то только как опцию отображения. Иначе искать по первым символам станет сложнее.
А вот про опцию автогруппировки в списке общих модулей я полностью за https://github.com/SeiOkami/OneS/issues/117
Еще мне нужен Working set, т.е. рабочий набор объектов. Временный набор объектов с которыми я работаю по задаче, а остальные чтобы были скрыты и не заставляли постоянно искать нужное фильтром или прокруткой на километры. Этот временный набор не хранится в конфигурации, а хранится в настройках конфигуратора конкретной базы и пользователя ОС. Описал идею в заявках по EDT https://github.com/marmyshev/edt-plugins/issues/2#issuecomment-821580627
