С недавних пор в метаданных появились модули менеджеров.
Описалово с диска ИТС :
"
...Позволяет описать методы для объекта конфигурации ... которые относятся ... к самому объекту конфигурации.
Например в модуле менеджера справочника Контрагенты может быть описана экспортная функция ПолучитьСписокДебиторов().
"

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

Для того их и создавали.
Чтобы не плодить общих модулей.
ИМХО,

(1) Где эти "новые веяния" в типовых?

(2) Вот сегодня отлаживал "Реализацию..." в "УПП", в модуле менеджера там, например, печать "Торг 12".

(2) сорри, туплю, не прочитал вопрос :)

(0) будет. Оно для того и придумано

из менеджера объекта потом можно будет вызвать экспортную процедуру/функцию не создавая экземпляр объекта?

(6) да, в этом и смысл модуля менеджера

(6) Не совсем понял, как не создавая экземпляр?

(7) По сути это общий модуль, только он "прилеплен" к объекту?

(8) Документы.ОтчетОПропажах.Печать(Ссылка, ИмяПечатнойФормы);

(8) Это значит не делая так:

ДокументОбъект = Документы.РеализацияТоваровУслуг.СоздатьДокумент()

(10) Прикольно :-)
спс

(10) ОтчетОПропажах - это вид документа конфигурации "Бюро находок" :-) или тупо опечатка? :-)

(11) спс
(13) Наверное хотел написать Продажи

вам, господа, чувства юмора в этом месяце не выдавали или в прошлом перерасход случился?

(14) Это юмор, вообще-то. Знакомо значение слова? :)

(13)(14) жгёте

Справочник.Валюты и общий модуль управления валютами "Валюты" это две большие разницы на абстрактном уровне.

(18) Например, функция получения курсов валют. Причем тут справочник?

(19) потому что без собственно справочника валют она бесполезна, не?

(18) а, если не секрет, что ты сейчас поимел в виду под абстрактным уровнем такого, из чего следует (19)?

по сути это отдельный модуль, но очень хорошо запихнутый по неймспейсу в нужное место.

рекомендуется к использованию

Общие модули это вообще атавизм программирования

"Общие модули это вообще атавизм программирования" -хз.. я слаб в 8-ке... но вот куда по 8-ой идеологи и  следует положить функцию/процедуру, которая возвращает размер "рюкзака"..? например - подбоп товара на паллету с ограничением по вместимости? подобор суммы под требуемую?

я, например, для тонкого клиента не нашел места для функции, которая должна быть доступна как из формы документа, так и из модуля - только менеджер объекта

(23) из того, что в 1С - больше некуда, не следует, что ОМ - это не атавизм

(23) Положить ее надо в класс рюкзак , что бы всегда знать в каком объекте ее найти
не кажется ли вам логично, что функция размер рюкзака лежит в рюкзаке?

(26) а функция сумки в сумке ?

полиморфизмом пахнет

(27) а почему бы и нет?

(28) в каждом тогда модуле менеджера будет вызов функции из ОМ =)

(29) зачем?

(30) код зачем повторять

(26)в Зиуп расчет по начислениям для нескольких доков, предлагаете из ОМ перетаскивать в модуль менеджера каждого дока? обработчики ТЧ аналогично во всех типовых, установка субконто в бухии, тоже предлагаете из ОМ для каждого дока копипастить?

Модуль менеджера создан для расширения встроенного языка. В нем мы можем экспортной функцией определить собственный метод (он автоматически появится в методах объекта), который будет доступен в глобальном контексте, то есть можем получить его "через точку" в любом месте конфигурации не создавая объекта.
(1) Никак не может заменить общие модули, в нем ничего кроме процедур и функций быть не должно, ни переменных, ни тела модуля.

в ж0пу общие модули, даёшь статические классы и ООП в 1с
валим процедурщиков толстой метлой

в 1с появились статические методы классов

Только удобство переноса общих функций вместе с объектом из одной конфигурации в другую.

(33) дас ис фантастиш!

а по моему модули менеджеров всегда были

я еще года полтора назад примерно писал в модуле менеджера справочника функции всякие

Так это же б0ян приб0ян!


http://blog.zfilin.org.ua/2010/05/1_25.html

"Снова статические методы классов в 1С
Я совершенно напрасно переживал по поводу статических методов классов, которых мне (и не только мне) так не хватает. В версии 1С 8.2 у объектов метаданных есть "Модуль менеджера" и функции описанные в нем фактически и являются статическими методами классов. Во всяком случае их можно так использовать.
Те, кто все понял, дальше могут не читать, с остальными давайте разберемся подробнее."

+(40)
v8: v8: Почему многие процедуры перенесены из модуля объекта в Модуль менеджера?

хрень все, нужен был модуль ссылки,
кто так пишет 21 веке? ПолучитьКурс(Ссылка,Дата)
православный стиль Ссылка.ПолучитьКурс(Дата) а для этого нужен модуль ссылки

(40)_ мааленькое незначительное отличие от статических
обычно из методов объекта к статическим можно обращаться непосрдественно по имени, в 1С 8.2 все же придется перед именем явно писать имя менеджера

Опа... 1С оказывается внедрила статические методы... круто.

(20) Без справочника валют половина программы бесполезна. Это не значит что надо эту половину пихать в модуль менеджера справочника валюты. И почему именно справочника? Почему не в регистр курсов валют? У него тоже есть модуль менеджера, чем он хуже?

(21) О том что там должны быть функции именно Этого справочника, а не некоторой системы объединяющей справочник, регистр сведений и т.п.

(42) Чтобы так писать - нужно иметь наследование.
Так как ПолучитьКурс(Ссылка,...) будет вызываться даже если ссылка=Неопределено, и эту ситуацию мы должны разрулить уже внутри функции.
В случае же вызова через точку система выдаст ошибку, так как ссылка не определена.
Другое дело, что хотелось быть иметь объекты с наследуемыми свойствами, чтобы можно было определить функцию для одного объекта, а для остальных - наследовать (то есть иметь прототипы классов).

Спор остроконечников с тупоконечниками :)

По итогам обсуждения пришел к такому заключению:
по-сути общий модуль от модуля менеджера отличается только местом хранения (с точки зрения разработчика приложения) и способом вызова (нужно/не нужно указывать "класс").
Получается достаточно удобная штука. Функциональность, которую проблематично логически связать с одним объектом метаданных - желательно ложить в общий модуль. Функциональность, которую можно связать с конкретным объектом - в модуль соответствующего справочника, документа ...

Хотя в руках "умельцев" получается возможность функциональность справочника "пользователи" положить в модуль менеджера (например) регистра сведений "Цены номенклатуры".

(48) Там ещё важно, что в модуле менеджера у каждого объекта может быть функция с одинаковым именем, но разным содержимым, а если функция в глобальном модуле - то содержимое придётся проверять, чтобы для разных объектов выполнить различные действия.

Если есть справочник "Валюты" и регистр сведений "КурсыВалют", то спорить, где лучше разместить функцию ПолучитьКурс(Валюта,Дата) - можно до бесконечности :)

не в качестве спора, только имхо: утверждение "если функциональность использует конкретный объект - то она должна быть в менеджере этого объекта" - мне кажется спорно. Оно базируется на знаниях алгоритмов работы этой сущности. А это уже зависит от того, кто и как пишет эти алгоритмы...

Чтобы спорить на тему "идеологических" вопросов - надо, как минимум, знать эту самую "идеологию". "Откуда" она появилась и куда она "движется". Максимум - это знать "конечный пункт назначения".

(46) это понятно, но неизвестно что лучше
не будет ошибки, но будет "левый" результат - разве это лучше?

(51) Просто, ошибку в значении можно обработать внутри функции - в некоторых случаях подставив значение по умолчанию.
А ошибку вызова придётся при помощи попытка-исключение ловить.

справочники надо ликвидировтаь как класс вообще. Перевести все на регистры сведений. тогда и спора не будет

они создались для того чтобы не создавать объект.

(53) а как же ссылки?

55+ табличные части

(52) почему именно в исключении? не факт

(0) сабж создан не совсем для этого

сабж создан для создания типовых функций ориентированых на обьект методанных

пример:

вместо написания универсальной функции сохранитьВФайл(Ссылка) для 54 справочников и внутри парсинга типа, (и как следствие нечитабельного кода)

в каждом справочнике делаем сохранитьВФайл(Ссылка) экспорт

и где-то делаем ОДИН вызов справочники[Имя].сохранитьВФайл(Ссылка) уже не заботясь о типе...

зы
вспоминаем ООП...

модуль менеджера - едва ли не самая тривиальная хреновина во всей 8.2, чего тут тереть второй день?..

(58)на счет читабельности кода спорное утверждение. Может получится нехорошая ситуация когда будем иметь 50 функций в 50 модулях менеджера, которые содержат одинаковый код

неймспейсов жутко не хватает

(60) такого эффекта можно добиться и без модулей менеджера

(55,56) "Идите, ежики, нафиг! Я стратегическими вопросами занимаюсь..." ;-)

(60) вот как ни упирайся, а в самом низу будет
Если что-то="Иванов"

ну когда уже будет реализовано наследование и перегрузка методов?