В новой версии платформы «1С:Предприятие» доработан механизм расширений
В версии платформы 8.3.11 появится возможность добавлять к прикладному решению собственные структуры для хранения данных: справочники, документы и регистры сведений.
Теперь при добавлении в прикладное решение объектов и реквизитов, их данные будут сохраняться в информационной базе. А при доработке прикладного решения, с помощью расширений можно будет изменять структуру данных.
Чтобы заполнять новые структуры своими данными, нужно будет добавить или модифицировать соответствующий объект конфигурации и перезапустить сеанс.
Нововведение позволит добавить собственные:
С подробной информацией о принципах работы нового механизма можно ознакомиться в технологическом блоге разработчиков.
Ранее для платформы «1С:Предприятие 8.3.11» были анонсированы функции компактного хранения истории данных, выделения диапазонов строк и отображения единиц измерения, а также настройка объединения состава и типа объектов.
Теперь при добавлении в прикладное решение объектов и реквизитов, их данные будут сохраняться в информационной базе. А при доработке прикладного решения, с помощью расширений можно будет изменять структуру данных.
Чтобы заполнять новые структуры своими данными, нужно будет добавить или модифицировать соответствующий объект конфигурации и перезапустить сеанс.
Нововведение позволит добавить собственные:
- Справочники;
- Документы;
- Регистры сведений;
- Планы обмена;
- Реквизиты;
- Табличные части и их реквизиты.
С подробной информацией о принципах работы нового механизма можно ознакомиться в технологическом блоге разработчиков.
Ранее для платформы «1С:Предприятие 8.3.11» были анонсированы функции компактного хранения истории данных, выделения диапазонов строк и отображения единиц измерения, а также настройка объединения состава и типа объектов.
Автор:
Яна Казьмина
Редактор ленты новостей
Комментарии
Избранное
Подписка
Сортировка:
Древо
(15) да, принимаю ваше замечание.
Однако как мне видится, лучше бы под дополнительные реквизиты создавалась дополнительная таблица, в которой была бы колонка со ссылкой на сам объект и колонки доп.реквизитов. Однако это бы несколько снижало производительность запросов так как это еще одно соединение.
Однако как мне видится, лучше бы под дополнительные реквизиты создавалась дополнительная таблица, в которой была бы колонка со ссылкой на сам объект и колонки доп.реквизитов. Однако это бы несколько снижало производительность запросов так как это еще одно соединение.
О да, теперь заживем!
Интересное решение, что при расширении не создается новая таблица с ГУИДом и новыми колонками, а целая таблица переносится. Жесткая будет реструктуризация, если расширять или удалять расширение таблиц с тысячами элементов.
Интересное решение, что при расширении не создается новая таблица с ГУИДом и новыми колонками, а целая таблица переносится. Жесткая будет реструктуризация, если расширять или удалять расширение таблиц с тысячами элементов.
(23)Я хотел на мальдивы и всю жизнь пить коктейли глядя на бескрайнюю синюю гладь. А 1С извернулись и сделали возможность расширять функциональность конфигураций не снимая их с поддержки. Снова недоволен.
Можно и так написать. ООП и мальдивы с расширениями связывает только одно: они не имеют к ним никакого отношения.
Можно и так написать. ООП и мальдивы с расширениями связывает только одно: они не имеют к ним никакого отношения.
(30)
А вы не думаете, что создание расширения - это наследование, а изменение функций и типовых содытий в расширении - полиморфизм?
(23)
ИМХО ООП нафиг не нужно, какие проблемы с помощью него Вы будете решать?
1С и так заставляет мыслить разработчика терминами предметной области. Дополнительные абстракции тут не к чему.
А вы не думаете, что создание расширения - это наследование, а изменение функций и типовых содытий в расширении - полиморфизм?
(23)
ИМХО ООП нафиг не нужно, какие проблемы с помощью него Вы будете решать?
1С и так заставляет мыслить разработчика терминами предметной области. Дополнительные абстракции тут не к чему.
(32) Ну, пожалуй, это наследование. Только это какое-то уж такое, здоровенное такое наследование. Где в качестве родителя выступает вся конфигурация. Изменение функций и типовых событий - это скорее переопределение, а не полиморфизм. Впрочем, как раз и без полиморфизма-то можно и обойтись.
ИМХО: добавление в язык платформы объектных возможностей, как мне представляется, позволит справляться с растущей сложностью прикладных решений. Уже сейчас есть проблемы в этом направлении. Понятие класса, понятие какой-то группировки классов в пакеты (или иные кластеры), должно помочь. Серебряной пулей это, естественно, не будет. Но позволит справляться со сложностью.
ИМХО: добавление в язык платформы объектных возможностей, как мне представляется, позволит справляться с растущей сложностью прикладных решений. Уже сейчас есть проблемы в этом направлении. Понятие класса, понятие какой-то группировки классов в пакеты (или иные кластеры), должно помочь. Серебряной пулей это, естественно, не будет. Но позволит справляться со сложностью.
(33)
Но ведь есть Общие модули, модули менеджера, модули объекта. Этого вполне достаточно для уменьшения зависимостей.
Не хватает, возможно, закрытых переменных.
Но это решается, используя DTO. Т.е. мы переменные класса выделяем в структуру, а методы класса, сосредоточенные в общем модуле или модуле менеджера, производят изменения этой структуры.
Такой подход, например, в типовой обработке проведения в УТ11. Создаем структуру, где есть данные для проведения. При этом у нас есть методы с одинаковым названием для каждого документа, которые содержаться в модуле менеджера и возвращают набор записей. Они заполняют структуру, а потом наша "фабрика" записывает движения.
), должно помочь. Серебряной пулей это, естественно, не будет. Но позволит справляться со сложностью.
Но ведь есть Общие модули, модули менеджера, модули объекта. Этого вполне достаточно для уменьшения зависимостей.
Не хватает, возможно, закрытых переменных.
Но это решается, используя DTO. Т.е. мы переменные класса выделяем в структуру, а методы класса, сосредоточенные в общем модуле или модуле менеджера, производят изменения этой структуры.
Такой подход, например, в типовой обработке проведения в УТ11. Создаем структуру, где есть данные для проведения. При этом у нас есть методы с одинаковым названием для каждого документа, которые содержаться в модуле менеджера и возвращают набор записей. Они заполняют структуру, а потом наша "фабрика" записывает движения.