Переопределяемый модуль 1с что это
Переопределяемые и поставляемые объекты библиотеки
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. С точки зрения возможностей по настройке функциональности библиотеки для работы в конкретной конфигурации-потребителе все объекты библиотеки условно делятся на три категории:
- Непереопределяемые объекты – «готовые» объекты, которые можно брать и использовать в конфигурации-потребителе «как есть». Их не следует изменять в конфигурации-потребителе, чтобы они были гарантированно одинаковы во всех конфигурациях, основывающихся на данной библиотеке. Более того, такие объекты обязательно должны присутствовать в конфигурациях, использующих библиотеку. Примеры: справочник Пользователи .
- Переопределяемые объекты – «изменяемые» объекты для настройки библиотеки под конкретную конфигурацию. Они могут или должны быть изменены в конфигурации-потребителе. С помощью таких объектов решаются задачи изменения поведения библиотечной функциональности, ее параметризации спецификой конфигурации-потребителя, а также для подключения библиотечной функциональности к объектам конфигурации-потребителя.
- Определители типов – объекты-«классификаторы», которые не имеют базовой реализации. Предназначены для формирования единого пространства имен в конфигурациях, а реализация при этом может как угодно сильно различаться в конфигурациях-потребителях. Например: справочники-классификаторы, в которых определено только «название»; сущность «организация» должна быть везде представлена справочником с именем Организации и т.п.
2. Рекомендуется устанавливать для объектов этих категорий следующие правила поставки :
- Непереопределяемые объекты – «изменения не рекомендуются»;
- Переопределяемые объекты и определители типов – «изменения разрешены».
Эти рекомендации продиктованы следующими соображениями:
- Непереопределяемые объекты – это зона ответственности разработчиков библиотеки, поэтому они не должны разрабатываться «по месту» в конфигурациях-потребителях. Но если необходимость изменений носит срочный характер (например, исправление критичной ошибки) или продиктована какими-то другими особыми соображениями, то допускается вносить изменения в непереопределяемые библиотечные объекты непосредственно в конфигурациях-потребителях. При этом нужно иметь в виду, что эти изменения могут быть потеряны при следующем обновлении версии библиотеки в конфигурации-потребителе, если не принять специальные меры (донести до разработчиков библиотеки необходимость внесения изменений или задокументировать этот отход от общей инструкции по обновлению библиотеки).
- Переопределяемые объекты и определители типы должны или могут быть изменены в конфигурации-потребителе, исходя из их назначения.
3. Для того чтобы упростить настройку библиотеки и снизить трудоемкость последующих обновлений версии библиотеки в конфигурации-потребителе следует минимизировать количество переопределяемых объектов с помощью следующих методик:
- Настройка состава типов переопределяемых реквизитов (свойств) тех или иных объектов библиотеки – для подключения библиотечной функциональности к объектам конфигурации-потребителя.
Например: можно подключить библиотечную функциональность к конкретным объектам конфигурации с помощью расширения состава типов общей команды, измерения составного типа в регистре сведений и т.п. - Добавление предопределенных элементов – для параметризации библиотечной функциональности спецификой конфигурации-потребителя.
Например: для библиотечной подсистемы ведения и обработки контактной информации с помощью предопределенных элементов библиотечного справочника ВидыКонтактнойИнформации можно указать, какие виды контактной информации (телефон, адрес, электронный адрес и т.п.) должны быть предусмотрены для объектов конфигурации-потребителя. - Переопределяемые общие модули – для изменения поведения библиотечной функциональности в конкретной конфигурации-потребителе
- с помощью переопределения тех или иных «обработчиков событий», предоставляемых библиотекой; например:
ПриПодготовкеМакетаОписанияОбновлений
ПриЗаписиСпискаБизнесПроцессов - а также для того, чтобы сообщить ту или иную информацию из конфигурации-потребителя в библиотеку. Например:
ПриОпределенииБазовойВерсииКонфигурации
ПриДобавленииОбработчиковОбновления
3.1. Переопределяемые общие модули следует называть с постфиксом Переопределяемый .
3.2. Переопределяемые общие модули должны содержать только экспортные процедуры, которые вызываются из кода самой библиотеки. Другими словами, не следует допускать вызовов процедур переопределяемых модулей непосредственно из кода конфигурации-потребителя.
Такое ограничение обусловлено соображением повышения устойчивости кода конфигурации, который вызывает библиотечные процедуры и функции, составляющие программный интерфейс библиотеки. К программному интерфейсу библиотеки следует относить только экспортные процедуры и функции непереопределяемых общих модулей.
Например, в библиотеке имеются модули ПапкиФайлов и ПапкиФайловПереопределяемый . Для использования в конфигурациях-потребителях в модуле ПапкиФайлов реализуется экспортная функция:
Функция ПапкаФайлов(ВладелецФайловСсылка) Экспорт
СтандартнаяОбработка = Истина;
Результат = Неопределено;
ПапкиФайловПереопределяемый.ПриПолученииПапкиФайлов(ВладелецФайловСсылка, Результат, СтандартнаяОбработка);Если СтандартнаяОбработка Тогда
// реализация по умолчанию
Результат = .
КонецЕсли;
Возврат Результат;а в модуле ПапкиФайловПереопределяемый - процедура-обработчик ПриПолученииПапкиФайлов :
// Вызывается из библиотеки при необходимости получить папку файлов для указанного владельца.
//
// Параметры:
// ВладелецФайловСсылка – ЛюбаяСсылка - владелец файлов, для которого нужно вернуть папку.
// ПапкаФайлов – СправочникСсылка.ПапкиФайлов - в этот параметр нужно записать результат.
// СтандартнаяОбработка – Булево - по умолчанию, Истина. В этом случае папка будет получена способом по умолчанию.
// Если значение параметра установить в Ложь, то в этой процедуре можно реализовать свой способ,
// которым в конфигурации получают папки файлов.
//
Процедура ПриПолученииПапкиФайлов(ВладелецФайловСсылка, ПапкаФайлов, СтандартнаяОбработка) ЭкспортПри этом все вызовы из конфигурации-потребителя должны идти только к библиотечному модулю ПапкиФайлов . Обращение к ПапкиФайловПереопределяемый разрешается только из библиотечного модуля ПапкиФайлов .
3.3. При этом в переопределяемом модуле следует располагать только экспортные процедуры с пустой реализацией. В нем не должно быть каких-либо других не-экспортных процедур или функций. Базовую реализацию переопределяемых процедур и функций следует располагать в непереопределяемом коде.
Такое ограничение вызвано необходимостью снизить трудоемкость последующих обновлений переопределяемых модулей в конфигурации-потребителе.
Например, неправильно поставлять переопределяемый модуль МояБиблиотекаПереопределяемый с какой-либо реализацией:Функция НастройкаПараметровРаботы() Экспорт
ПараметрыРаботы = Новый Структура;
// если настройки по умолчанию не подходят, то измените их.
ПараметрыРаботы.Вставить("ПоказыватьЕдинственныйРаздел", Ложь);
ПараметрыРаботы.Вставить("ЗадаватьДатуДляПрочихРазделов", Ложь);
ПараметрыРаботы.Вставить("ИспользоватьВнешнихПользователей", Ложь);
Возврат ПараметрыРаботы;// Позволяет настроить работу подсистемы.
//
// Параметры:
// ПараметрыРаботы - Структура - содержит свойства:
// * ПоказыватьЕдинственныйРаздел - Булево - по умолчанию Ложь.
// * ЗадаватьДатуДляПрочихРазделов - Булево - по умолчанию Ложь.
// * ИспользоватьВнешнихПользователей - Булево - по умолчанию Ложь.
//
Процедура ПриПолученииНастроекПараметровРаботы(ПараметрыРаботы) Экспорта установку значений по умолчанию перенести в непереопределяемый общий модуль библиотеки:
ПараметрыРаботы = Новый Структура;
// настройки по умолчанию
ПараметрыРаботы.Вставить("ПоказыватьЕдинственныйРаздел", Ложь);
ПараметрыРаботы.Вставить("ЗадаватьДатуДляПрочихРазделов", Ложь);
ПараметрыРаботы.Вставить("ИспользоватьВнешнихПользователей", Ложь);// а теперь запросим конфигурацию-потребитель на случай,
// если эти умолчания не устраивают
МояБиблиотекаПереопределяемый.ПриПолученииНастроекПараметровРаботы(ПараметрыРаботы);
Возврат ПараметрыРаботы;3.4. При обновлении версии библиотеки в конфигурации-потребителе особого внимания требуют модули корневого объекта конфигурации и переопределяемые общие модули, так как автоматическое обновление таких «узких мест» конфигурации-потребителя невозможно. Для настройки в конфигурации переопределяемых общих модулей рекомендуется придерживаться общего подхода:
Переопределяемые и поставляемые объекты библиотеки
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1. С точки зрения возможностей по настройке функциональности библиотеки для работы в конкретной конфигурации-потребителе все объекты библиотеки условно делятся на три категории:
- Непереопределяемые объекты – «готовые» объекты, которые можно брать и использовать в конфигурации-потребителе «как есть». Их не следует изменять в конфигурации-потребителе, чтобы они были гарантированно одинаковы во всех конфигурациях, основывающихся на данной библиотеке. Более того, такие объекты обязательно должны присутствовать в конфигурациях, использующих библиотеку. Примеры: справочник Пользователи .
- Переопределяемые объекты – «изменяемые» объекты для настройки библиотеки под конкретную конфигурацию. Они могут или должны быть изменены в конфигурации-потребителе. С помощью таких объектов решаются задачи изменения поведения библиотечной функциональности, ее параметризации спецификой конфигурации-потребителя, а также для подключения библиотечной функциональности к объектам конфигурации-потребителя.
- Определители типов – объекты-«классификаторы», которые не имеют базовой реализации. Предназначены для формирования единого пространства имен в конфигурациях, а реализация при этом может как угодно сильно различаться в конфигурациях-потребителях. Например: справочники-классификаторы, в которых определено только «название»; сущность «организация» должна быть везде представлена справочником с именем Организации и т.п.
2. Рекомендуется устанавливать для объектов этих категорий следующие правила поставки :
- Непереопределяемые объекты – «изменения не рекомендуются»;
- Переопределяемые объекты и определители типов – «изменения разрешены».
Эти рекомендации продиктованы следующими соображениями:
- Непереопределяемые объекты – это зона ответственности разработчиков библиотеки, поэтому они не должны разрабатываться «по месту» в конфигурациях-потребителях. Но если необходимость изменений носит срочный характер (например, исправление критичной ошибки) или продиктована какими-то другими особыми соображениями, то допускается вносить изменения в непереопределяемые библиотечные объекты непосредственно в конфигурациях-потребителях. При этом нужно иметь в виду, что эти изменения могут быть потеряны при следующем обновлении версии библиотеки в конфигурации-потребителе, если не принять специальные меры (донести до разработчиков библиотеки необходимость внесения изменений или задокументировать этот отход от общей инструкции по обновлению библиотеки).
- Переопределяемые объекты и определители типы должны или могут быть изменены в конфигурации-потребителе, исходя из их назначения.
3. Для того чтобы упростить настройку библиотеки и снизить трудоемкость последующих обновлений версии библиотеки в конфигурации-потребителе следует минимизировать количество переопределяемых объектов с помощью следующих методик:
- Настройка состава типов переопределяемых реквизитов (свойств) тех или иных объектов библиотеки – для подключения библиотечной функциональности к объектам конфигурации-потребителя.
Например: можно подключить библиотечную функциональность к конкретным объектам конфигурации с помощью расширения состава типов общей команды, измерения составного типа в регистре сведений и т.п. - Добавление предопределенных элементов – для параметризации библиотечной функциональности спецификой конфигурации-потребителя.
Например: для библиотечной подсистемы ведения и обработки контактной информации с помощью предопределенных элементов библиотечного справочника ВидыКонтактнойИнформации можно указать, какие виды контактной информации (телефон, адрес, электронный адрес и т.п.) должны быть предусмотрены для объектов конфигурации-потребителя. - Переопределяемые общие модули – для изменения поведения библиотечной функциональности в конкретной конфигурации-потребителе
- с помощью переопределения тех или иных «обработчиков событий», предоставляемых библиотекой; например:
ПриПодготовкеМакетаОписанияОбновлений
ПриЗаписиСпискаБизнесПроцессов - а также для того, чтобы сообщить ту или иную информацию из конфигурации-потребителя в библиотеку. Например:
ПриОпределенииБазовойВерсииКонфигурации
ПриДобавленииОбработчиковОбновления
3.1. Переопределяемые общие модули следует называть с постфиксом Переопределяемый .
3.2. Переопределяемые общие модули должны содержать только экспортные процедуры, которые вызываются из кода самой библиотеки. Другими словами, не следует допускать вызовов процедур переопределяемых модулей непосредственно из кода конфигурации-потребителя.
Такое ограничение обусловлено соображением повышения устойчивости кода конфигурации, который вызывает библиотечные процедуры и функции, составляющие программный интерфейс библиотеки. К программному интерфейсу библиотеки следует относить только экспортные процедуры и функции непереопределяемых общих модулей.
Например, в библиотеке имеются модули ПапкиФайлов и ПапкиФайловПереопределяемый . Для использования в конфигурациях-потребителях в модуле ПапкиФайлов реализуется экспортная функция:
Функция ПапкаФайлов(ВладелецФайловСсылка) Экспорт
СтандартнаяОбработка = Истина;
Результат = Неопределено;
ПапкиФайловПереопределяемый.ПриПолученииПапкиФайлов(ВладелецФайловСсылка, Результат, СтандартнаяОбработка);Если СтандартнаяОбработка Тогда
// реализация по умолчанию
Результат = .
КонецЕсли;
Возврат Результат;а в модуле ПапкиФайловПереопределяемый - процедура-обработчик ПриПолученииПапкиФайлов :
// Вызывается из библиотеки при необходимости получить папку файлов для указанного владельца.
//
// Параметры:
// ВладелецФайловСсылка – ЛюбаяСсылка - владелец файлов, для которого нужно вернуть папку.
// ПапкаФайлов – СправочникСсылка.ПапкиФайлов - в этот параметр нужно записать результат.
// СтандартнаяОбработка – Булево - по умолчанию, Истина. В этом случае папка будет получена способом по умолчанию.
// Если значение параметра установить в Ложь, то в этой процедуре можно реализовать свой способ,
// которым в конфигурации получают папки файлов.
//
Процедура ПриПолученииПапкиФайлов(ВладелецФайловСсылка, ПапкаФайлов, СтандартнаяОбработка) ЭкспортПри этом все вызовы из конфигурации-потребителя должны идти только к библиотечному модулю ПапкиФайлов . Обращение к ПапкиФайловПереопределяемый разрешается только из библиотечного модуля ПапкиФайлов .
3.3. При этом в переопределяемом модуле следует располагать только экспортные процедуры с пустой реализацией. В нем не должно быть каких-либо других не-экспортных процедур или функций. Базовую реализацию переопределяемых процедур и функций следует располагать в непереопределяемом коде.
Такое ограничение вызвано необходимостью снизить трудоемкость последующих обновлений переопределяемых модулей в конфигурации-потребителе.
Например, неправильно поставлять переопределяемый модуль МояБиблиотекаПереопределяемый с какой-либо реализацией:Функция НастройкаПараметровРаботы() Экспорт
ПараметрыРаботы = Новый Структура;
// если настройки по умолчанию не подходят, то измените их.
ПараметрыРаботы.Вставить("ПоказыватьЕдинственныйРаздел", Ложь);
ПараметрыРаботы.Вставить("ЗадаватьДатуДляПрочихРазделов", Ложь);
ПараметрыРаботы.Вставить("ИспользоватьВнешнихПользователей", Ложь);
Возврат ПараметрыРаботы;// Позволяет настроить работу подсистемы.
//
// Параметры:
// ПараметрыРаботы - Структура - содержит свойства:
// * ПоказыватьЕдинственныйРаздел - Булево - по умолчанию Ложь.
// * ЗадаватьДатуДляПрочихРазделов - Булево - по умолчанию Ложь.
// * ИспользоватьВнешнихПользователей - Булево - по умолчанию Ложь.
//
Процедура ПриПолученииНастроекПараметровРаботы(ПараметрыРаботы) Экспорта установку значений по умолчанию перенести в непереопределяемый общий модуль библиотеки:
ПараметрыРаботы = Новый Структура;
// настройки по умолчанию
ПараметрыРаботы.Вставить("ПоказыватьЕдинственныйРаздел", Ложь);
ПараметрыРаботы.Вставить("ЗадаватьДатуДляПрочихРазделов", Ложь);
ПараметрыРаботы.Вставить("ИспользоватьВнешнихПользователей", Ложь);// а теперь запросим конфигурацию-потребитель на случай,
// если эти умолчания не устраивают
МояБиблиотекаПереопределяемый.ПриПолученииНастроекПараметровРаботы(ПараметрыРаботы);
Возврат ПараметрыРаботы;3.4. При обновлении версии библиотеки в конфигурации-потребителе особого внимания требуют модули корневого объекта конфигурации и переопределяемые общие модули, так как автоматическое обновление таких «узких мест» конфигурации-потребителя невозможно. Для настройки в конфигурации переопределяемых общих модулей рекомендуется придерживаться общего подхода:
Привет! Кто может помочь?
Я программист 1С8 (опыт работы с 2014, с лета 2016 работаю в 1С Франчайзи). Но с Расширениями имею дело впервые.
Инфы нашел достаточно:
http://v8.1c.ru/o7/201410ext/
http://catalog.mista.ru/public/369451/
но это - как на стандартную задачу наложить Расширение.
И все вроде понятно.
А у меня задача ОБРАТНАЯ. Имеется у клиента несколько доработанных баз (оттого, проблемы со стандартными обновлениями). Требуется - доработки по максимуму вынести в Расширения, оставив БД максимально приближенные к Стандартным.
И я совершенно не понимаю как это сделать! Не нашел - какой там механизм?
Кто может "на пальцах" объяснить?
Сначала определяю все интересующие меня объекты - сравнить конфигурацию с конфой поставщика, эт просто.
Создать в исходной нестанд. конфе новое расширение - создал.
А дальше?
Перенести все измененные объекты в Расширение?
Так переносятся ТОЛЬКО формы. А мне ж надо и модуль, и все команды - мне их вручную заполнять?
(Например, Отчет1, совсем новый. Ладно, делаю его внешним и Расширение - вставить. А "прототип" из исходной конфы убираю.
Ругается - требует "не обнаружен в конфе". Какое . если я ясно прочел что в Расширении ДОЗВОЛЕНЫ НОВЫЕ отчеты и обработки - отсутствующие в конфе? Или я не так понял??)
Еще вопрос - вот в Док или Спр изменена Форма. Еще появился / был изменен реквизит - но тут сказано, реквизиты можно оставить, их будем по-прежнему вручную обновлять, раз их расширение не берет.
Переношу Форму (заодно перелетает весь Объект в дерево, Ок!). А поле модуля чистое. Понимаю, что это значит - использовать модули конфы. А как мне изменения перенести - вручную копировать все процедуры где измененный текст - с префиксом расширения перед именем? Ладно, делаю так - а что делать, если внутри еще обращения к процедурам (другим в модуле формы, или в модуле Менеджера, или среди Общих модулей?).
Перенес, ругается.
Мне тогда "охватом" все их тоже переносить? Общие - ладно. А прочие модули той же формы (к которым ссылки) - их куда? И ставить ли перед ними префикс расширения?
В общем, крутился, не получается.
ЧТО делаю не так?Не понятно конкретно:
1) если объект новый. Как его ПОЛНОСТЬЮ перенести?
1а - добавить - модули не переносятся.
1б при удалении "прототипа", ругается.
2) если объект лишь изменен. ЧТО переносить? ФОрму измененную перенести, ладно. А модули как - я ж написал?
Если команда и "стерильно" чистая - ладно, прописано по ссылке.
А если она ссылается на другую процедуру, ее тоже переносить? С префиксом РАсш - или это лишь для команд?
3) Я главного не понимаю. Какие Объекты конфы видны из Расширения? Или их все (к которым ссылки) надо переносить?
4) насколько обязательно для Расширения наличие "прототипа"? Вот если новая форма, или макет. Переношу, а из конфы удаляю. Ругается!
5) совместимость! Даже в гугле в одних пишут - ставить "не использовать совместимость", в других - "ставить 8.3.9" (чтоб можно было расширять и модули объекта, и модули менеджера). Так что писать??
6) и общие модули - даже в гугле встретил что "не все". А какие.
7) наконец, а что со Свойствами делать? Вот в различии/ сравнении конф, выдало что например в Свойствах формы стоит что-то иное. А в Расширении это поле на форма/свойства вообще отсутствует, что с этим делать?(0) рашсирения это только обработки и отчеты. максимум формы.
больше НИЧЕГО
никаких реквизитов или обьектовПовторяю, когда я перенес Отчет (сначала, сделал как обычно, Добавить в Расширение - модуль и команды пустые!) - тогда я исходный сохранил как Внешний, и в Расширении на него заменил. Модуль и команды перенеслись.
Ругается, не работает.
Аналогично - при переносе отдельной Формы. Удаление "прототипа" - и ругань. В чем дело?
3) и вопрос - ЧТО ВИДНО из Расширения? Или мне тупо вручную, по перенесенным модулям отслеживать ВСЕ ссылки и соответствующее переносить?
Я так понимаю, что перенос есть ДВУХ типов.
а)) - переносим то что меняем. Объекты не любые а строго из списка (формы, обработки, отчеты, с 8.9 - еще что-то).
б)) - то что НЕ меняем - но там есть ссылки, по которым обращается из а)).
Верно?
И что НЕ перенесено по группе б) - Расширение просто не видит?
Или я ошибаюсь?
Тогда отчего ругается?Спасибо.Читаю.
Но если что - вернусь с вопросами.
(просто я не на работе счас - и до баз данных и практики доберусь лишь вечером, а то и в понедельник)(5) Вы уже утомили по десять раз в каждом посте повторять про чью-то там ругань.
Либо позовите специалиста, либо, если хотите, чтобы тут помогли, задайте конкретный вопрос с описанием того в каком месте что не работает, и как выглядит эта ваша ругань.
Отчеты и обработки абсолютно нормально выносятся в расширение.
Предположу, что если Вы делали через выгрузку во внешний отчет (обработку), то потеряли по дороге модуль менеджера (у внешних отчетов/обработок модуля менеджера нет, т.к. нет самого менеджера). Если я прав, то достаточно просто перенести модуль менеджера из исходного объекта основной конфигурации в объект, который у вас теперь в расширении.Спасибо.
Но все же вопрос (вот прочел по ИТС ссылке - не нашел).
Верно ли я понял, что Расширение - НЕ ВИДИТ объектов основной конфы, если я их не перенес?
(например, если в измененной конфе есть Константа, или Регистр - и к нему идет обращение. Обязательно надо перенести и этот объект тоже?)(9) Смотря что понимать под "видит". Если есть например константа в основной конфе и ты в раширении в обработке устанавливаешь значение этой константы то все будет ок, за исключением нескольких моментов. В расширении константа не видна при автодополнении кода, т.е. ты пишешь Константы. и имя константы из основной конфы показано не будет, при этом синтаксический контроль ругаться не будет. Константа также не будет видна в конструкторе запроса.
Рекомендую создать пустую базу и экспериментировать - это самый быстрый путь.Единственным ограничением расширений являеится невозможность добавления некоторых объектов метаданных и их реквизитов. Для себя делаю так. Надо добавить новый док - добавляем в основную конфу, но форму, модуль менеджера, модуль объекта - все это описываем уже в расширении. В общем в расширении все кроме самих скелетов объектов метаданных.
И последнее, надо учесть что из основной конфы модули расширения не видны. При этом из одного расширения видно другое без проблем, независимо от порядка их подключения
Так надо чтоб режим совместимости основной конфигурации (равно как и расширения) был не ниже 8.3.10, чтобы новые объекты и реквизиты можно было добавлять
Резюмирую: Заимствовать надо объекты конфигурации поставщика, а все изменения и интерфейсного и модульного порядка делать в расширении. Отлично работает. У меня куча, БОЛЬШАЯ куча доработок. ВСЕ перенес на расширения. Не вешаю на конфу замок только потому, что пока поставщик делает все конфы с совместимостью с 8.3.8. Как только режим совместимости повысят, вообще закрою конфу
(15) Подкреплять слова "рашсирения это только обработки и отчеты. максимум формы . никаких реквизитов или объектов" фразой "нельзя добавить свой справочник" - сильно.
(16) ну и? где противоречия ты увидел?
Я от 1С уже 15 лет жду чтобы можно было свою подсистему с любыми метаданными добавлять в типовую.
Вести ее отдельно, разрабатывать. Потом подключать к базе данных. В том числе естественно со справочниками и документами и прочими обьектами которые также и БД расширяют.А пока что все на уровне форм, отчетов и обработок. Полноценно задача не решена. Хотя обещалось что с выходом восьмерки решения будут блоковыми (хотя может я не правильно воспринял)
Пока что если ты что то дописываешь в типовой - даже нельзя поставку сделать без типовой.
(17) а для меня если нельзя добавить справочники, документы. регистры - это все равно что ничего)) Остальное вообще даже не волнует.
(19) Конечно, если вы, условно, из УТ делаете Автосервис, тогда - ДА, расширения не помогут. Но они и не предназначены для этого. А если вам надо скорректировать движения, добавить реквизит, доп расчет, автоматическое заполнение и т.п., то расширение - то что надо. Да, они и в таких задачах еще не все умеют, но скорость прогресса в возможностях впечатляет(сравните 8.3.8 и 8.3.10 - велосипед и авто). Так что .
(18) "где противоречия ты увидел?" // Ты утверждаешь несколько пунктов, а подтверждаешь только последний из них
(20) да я тоже надеюсь. А так кстати и на безрыбье рыба.
Кстати вот наверное сейчас все обработки перенесу в расширения.В статье рассмотрен один из вариантов библиотечного подхода к разработке, позволяющий организовать иерархический вызов библиотечных процедур и упростить автоматическую сборку готового продукта из нескольких библиотек. Предлагаемый подход может служить одним из элементов CI/CD при разработке ПО на платформе 1С.
Для разработки сложного программного обеспечения, фирма 1С рекомендует использовать библиотечный подход. Он описан, например, в Сумма = Количество * Цена
Этот расчет – функционал базовой библиотеки, которая будет лежать в основе остальных библиотек.
Возможно нам понадобится расчет налогов. Не вдаваясь в тонкости налогового учета, допустим что налог – это некая сумма, рассчитанная по ставке и просто добавляемая к основной сумме.
Аналогичным образом формализуем учет скидок:
Каждая из этих формул, а также объекты, содержащие все необходимые для расчета данные, реализованы в своей библиотеке. Но проблема в том, что запуск расчета производится в форме документа, в базовой библиотеке, в которой может быть ничего не известно о функционале, да и вообще о наличии других библиотек. Классический подход подразумевает реализацию в базовой библиотеке переопределяемого модуля расчета суммы, который в итоговой конфигурации должен быть дополнен (изменен) вызовами методов других библиотек.
Но можно поступить иначе. Предположим, в итоговой конфигурации у нас есть некий перечень методов, вызывая которые, мы сделаем все необходимые расчеты. Список этих методов может быть различным, в зависимости от конкретной конфигурации. Каждый метод реализован в модуле своей библиотеки. Все что нужно сделать при запуске расчета в базовой библиотеке – это передать такой перечень механизму, который обработает каждый элемент этого списка. Но где задать нам этот список методов? Опять использовать переопределяемый модуль и получить проблемы с обновлением? А пусть он создается сам, в зависимости от наличия той или иной библиотеки! Давайте придумаем некий механизм, который в зависимости от наличия каких-нибудь объектов метаданных, поймет, какие методы каких модулей надо включить в список для выполнения расчета. Здесь появляется небольшая проблема: для поиска среди объектов метаданных можно использовать только имя, а объекты одного вида с одинаковым именем создавать нельзя. Т.е. нельзя в каждой библиотеке создать свой общий модуль с именем "РасчетСуммы" и объединить их в одну конфигурацию. Но можно создавать подсистемы с одинаковыми именами, если они принадлежат разным родителям. Получается следующая схема:
Для каждой библиотеки создана своя подсистема, в которой есть подсистема с именем "РасчетСумм". В составе последних включены общие модули, в которых реализован экспортный метод, выполняющий расчет (имена методов также одинаковы). Подсистемы библиотек лежат в пределах одной группы, для упрощения поиска. Таким образом, ориентируясь на имя подсистем "РасчетСумм" мы легко можем получить список модулей и методов для проведения расчета.
Несколько слов по поводу выполнения этих методов. Самый простой вариант – создание некоего "менеджера", который будет последовательно вызывать каждую процедуру. Но я решил остановиться на другом способе – вызывать самую последнюю процедуру из списка и передавать ей управление. Решение о вызове предыдущего метода полностью возлагается на эту процедуру. Такой вариант более гибок – предыдущий метод может быть вызван в любом месте, а может и быть просто проигнорирован, если в нем нет нужды. Порядок методов в списке определяется порядком расположения подсистем библиотек внутри "ПереопределяемыеОбъектыБиблиотек".
Как это выглядит на практике:
В документе "Продажа" реализована команда:
В серверной процедуре получаем последовательность описаний методов и запускаем выполнение последнего из них. В нашем случае это будет РасчетСуммСоСкидкой.РасчетСумм
В процессе расчета мы сначала выполняем предыдущий метод РасчетСуммСНалогом.РасчетСумм, а затем производим обработку скидки.
Перед налоговым расчетом мы так же вызываем предыдущий метод РасчетСуммБазовый.РасчетСумм:
В котором выполняем самый первый расчет.
в последнем случае метод УправлениеБиблиотеками.ВыполнитьПредыдущуюПроцедуруНаСервере не выполнит ничего, так как предыдущих процедур не осталось.
Описанный выше механизм можно применять и для других целей, например для создания общего списка строковых или табличных ресурсов. Вот так реализовано описание конфигурации, которое создается на основе табличных макетов, принадлежащих разным библиотекам:
В обработке "Инфо" создается общий табличный документ:
Как внедрять или обновлять получившиеся библиотеки.
Процесс внедрения и обновления библиотек – обычное сравнение объединение конфигураций. В этом режиме надо отметить объекты по подсистемам файла:
и выполнить объединение. При этом никаких других действий, таких как редактирования модулей, делать не надо.
Подобное объединение можно проводить в автоматическом режиме. Для этого служит специальная команда пакетного режима конфигуратора. Пример такой команды:
здесь c:\bases\prod\ - путь к файловой базе, c:\bases\lib1.cf - конфигурация библиотеки, c:\bases\UpdLib1Settings.xml - файл настроек объединения.
здесь мы указываем, что не меняем свойства конфигурации, разрешаем удалять объекты, помечаем для объединения объекты нужных нам подсистем. Обратите внимание, что каждую подсистему мы указываем дважды: в новой конфигурации (для добавленных и измененных объектов) и в основной конфигурации (для измененных и удаленных объектов).
В результате обновления мы получим итоговую конфигурацию, в которой может быть (а может и не быть) одна или две библиотеки. Существуют несложные средства, которые позволят нам так же автоматически поместить эти изменения в хранилище 1С или же в Git.
Итак, вот что мы получили: базовую библиотеку и две дополнительные библиотеки, на основе которых можем в автоматическом режиме собрать четыре разные конфигурации для разных заказчиков. Эти конфигурации различаются по функциональным возможностям и могут иметь разную продажную стоимость, что позволит более гибко составлять коммерческие предложения.
Конечно же, предлагаемый подход не панацея. Так, он не поможет при работе с определяемыми типами, с переопределяемыми макетами и некоторыми другими объектами, но облегчить работу он может значительно. Надо отметить, что и стандартные возможности платформы включают в себе нечто подобное, хотя и менее функциональное. Это - подписки на события.
Рассмотренный пример вы можете увидеть в приложенном к статье файле. Это архив, содержащий в себе:
- Папка base – базовая библиотека
- Папки lib1, lib2 – 2 библиотеки
- Папка prod – итоговая конфигурация
- 1_CreateBase.bat – пакетный файл для создания итоговой конфигурации на основе базовой библиотеки
- 2_AddLib1.bat, 3_AddLib2.bat – пакетные файлы для первоначального внедрения в итоговую конфигурацию библиотек lib1, lib2
- 4_UpdLib1.bat, 5_UpdLib2.bat – пакетные файлы для обновления в итоговой конфигурации библиотек lib1, lib2
- *Settings.xml – файлы с настройками объединения
Желательно чтобы все эти папки и файлы находились в каталоге c:\bases, так как в пакетных файлах используются абсолютные пути. Также надо указать путь к файлу 1cv8.exe в зависимости от версии платформы.
Правила создания общих модулей
Область применения: управляемое приложение, мобильное приложение, обычное приложение.
1.1. Общие модули создаются для реализации процедур и функций, объединенных по некоторому признаку. Как правило, в один общий модуль помещаются процедуры и функции одной подсистемы конфигурации (продажи, закупки) или процедуры и функции сходного функционального назначения (работа со строками, общего назначения).
1.2. При разработке общих модулей следует выбирать один из четырех контекстов выполнения кода:
Тип общего модуля Пример наименования Вызов сервера Сервер Внешнее соединение Клиент
(обычное приложение)Клиент
(управляемое приложение)1. Серверный ОбщегоНазначения (или ОбщегоНазначенияСервер) 2. Серверный для вызова с клиента ОбщегоНазначенияВызовСервера 3. Клиентский ОбщегоНазначенияКлиент (или ОбщегоНазначенияГлобальный) 2.1. Серверные общие модули предназначены для размещения серверных процедур и функций, не доступных для использования из клиентского кода. В них реализуется вся внутренняя серверная бизнес-логика приложения.
Для корректной работы конфигурации в режимах внешнего соединения, управляемого и обычного приложений, серверные процедуры и функции следует размещать в общих модулях с признаками:- Сервер (флажок Вызов сервера снят),
- Клиент (обычное приложение) ,
- Внешнее соединение .
В таком случае гарантируется возможность вызова серверных процедур и функций с параметрами мутабельных типов (например, СправочникОбъект , ДокументОбъект и т.п.). Как правило, это:
Серверные общие модули называются по общим правилам именования объектов метаданных.
Например: РаботаСФайлами , ОбщегоНазначения .В отдельных случаях для предотвращения конфликта имен со свойствами глобального контекста может быть добавлен постфикс "Сервер" (англ. "Server" ).
Например: РегламентныеЗаданияСервер , ОбменДаннымиСервер, ScheduledJobsServer .2.2. Серверные общие модули для вызова с клиента содержат серверные процедуры и функции, доступные для использования из клиентского кода. Они составляют клиентский программный интерфейс сервера приложения.
Такие процедуры и функции размещаются в общих модулях с признаком:Серверные общие модули для вызова с клиента называются по общим правилам именования объектов метаданных и должны именоваться с постфиксом "ВызовСервера" (англ. "ServerCall" ).
Например: РаботаСФайламиВызовСервера, CommonServerCall .Следует иметь в виду, что экспортные процедуры и функции в таких общих модулях не должны содержать параметров мутабельных типов ( СправочникОбъект , ДокументОбъект и т.п.), так как их передача из (или в) клиентского кода невозможна.
2.3. Клиентские общие модули содержат клиентскую бизнес-логику (функциональность, определенную только для клиента) и имеют признаки:
- Клиент (управляемое приложение) ,
- Клиент (обычное приложение) .
Исключение составляют случаи, когда клиентские процедуры и функции должны быть доступны только в режиме управляемого приложения (только в режиме обычного приложения или только в режиме внешнего соединения). В таких случаях, допустима иная комбинация двух этих признаков.
Клиентские общие модули именуются с постфиксом "Клиент" (англ. "Client" ).
Например: РаботаСФайламиКлиент , ОбщегоНазначенияКлиент, StandardSubsystemsClient .2.4. Для того чтобы избежать дублирования кода, рекомендуется создавать клиент-серверные общие модули с теми процедурами и функциями, содержание которых одинаково на сервере и на клиенте. Такие процедуры и функции размещаются в общих модулях с признаками:
- Клиент (управляемое приложение) ,
- Сервер (флажок Вызов сервера сброшен),
- Клиент (обычное приложение) ,
- Внешнее соединение .
Общие модули этого вида именуются с постфиксом "КлиентСервер" (англ. "ClientServer" ).
Например: РаботаСФайламиКлиентСервер , ОбщегоНазначенияКлиентСервер, UsersClientServer .В то же время, как только возникает необходимость ветвить код в клиент-серверных общих модулях на серверный и клиентский, то не следует использовать для этого инструкции препроцессора. Вместо этого, функциональность, различную для клиента и для сервера, рекомендуется реализовывать по общим правилам в модулях соответствующего типа – см. пп. 2.1 и 2.3. Такое явное разделение клиентской и серверной бизнес-логики продиктовано соображениями повышения модульности прикладного решения, упрощения контроля со стороны разработчика над клиент-серверным взаимодействием и снижением риска ошибок из-за принципиальных отличий требований к разработке клиентского и серверного кода (необходимость минимизации кода, выполняемого на клиенте, разной доступностью объектов и типов платформы и др.). При этом нужно иметь в виду неизбежное увеличение числа общих модулей в конфигурации.
Особым случаем смешанных клиент-серверных модулей являются модули форм и команд, которые специально предназначены для реализации серверной и клиентской бизнес-логики в одном модуле.
3.1. Имена общих модулей рекомендуется строить по общим правилам именования объектов метаданных. Название общего модуля должно совпадать с названием подсистемы или отдельного механизма, процедуры и функции которой он реализует. Рекомендуется избегать в названиях общих модулей таких общих слов как "Процедуры", "Функции", "Обработчики", "Модуль", "Функциональность" и т.п. и применять их только в исключительных случаях, когда они более полно раскрывают назначение модуля.
Для того чтобы различать общие модули одной подсистемы, которые созданы для реализации процедур и функций, выполняемых в разных контекстах, рекомендуется задавать им постфиксы, описанные ранее в пп. 2.1-2.4.
3.2. Дополнительно к общим модулям могут быть добавлены уточняющие постфиксы.
3.2.1. Для глобальных модулей добавляется постфикс "Глобальный" (англ. "Global" ), в этом случае постфикс "Клиент" добавлять не следует.
Например: РаботаСФайламиГлобальный, InfobaseUpdateGlobal .3.2.2. Модули, выполняющиеся в привилегированном режиме, имеющие признак Привилегированный , именуются с постфиксом "ПолныеПрава" (англ. "FullAccess" ).
Например: РаботаСФайламиПолныеПрава .3.2.3. Модули, предназначенные для реализации на сервере или на клиенте функций с повторным использованием возвращаемых значений (на время вызова или на время сеанса), именуются с постфиксом "ПовтИсп" (англ. "Cached" ) и "КлиентПовтИсп" (англ. "ClientCached" ) соответственно.
Например: РаботаСФайламиКлиентПовтИсп, UsersInternalCached .3.2.4. Серверные и клиентские модули библиотечных конфигураций (которые предназначены не для самостоятельного использования, а для разработки других конфигураций) с процедурами и функциями, допускающие изменение своей реализации, именуются с постфиксами "Переопределяемый" (англ. "Overridable" ) и "КлиентПереопределяемый" (англ. "ClientOverridable" ).
Например: РаботаСФайламиКлиентПереопределяемый, CommonOverridable .3.2.5. В локализуемых конфигурациях, на базе которых выпускаются национальные прикладные решения для различных стран или регионов, модули, реализующие национальную специфику, именуются с постфиксами "Локализация" (англ. "Localization" ) и "КлиентЛокализация" (англ. "Client Localization " ).
Например: ЭлктроннаяПодписьЛокализация, ElectonicSignature Localization .Читайте также:
- Заметки расширение для браузера
- Краевой контраст в фотошопе где
- Microsoft office 2016 достоинства и недостатки
- Как изменить деления в диаграмме excel
- Файл не может быть открыт ядром базы данных microsoft jet
- с помощью переопределения тех или иных «обработчиков событий», предоставляемых библиотекой; например:
- с помощью переопределения тех или иных «обработчиков событий», предоставляемых библиотекой; например: