Скажем так, консультация об осуществимости некоей задумки.
А то прогеры не хотят делать, а силой я их прогибать не хочу (хочу в первую очередь понять, "а не дурак ли я").
Желательно скайпом или почтой.

а здесь не хочешь обсудить? больше людей - больше идей

В суровом Челябинске задумались о переходе на УФ?

задумка настолько некая, что даже на форуме стыдно озвучить?...

Идея уже есть.
Вопрос в том, насколько она осуществима.
в 7.7 я ее осуществлю легко.
а вот снеговика практически не знаю.
а программисты мозг парят....

(4) нам-то хорош мозг парить

1Сергей В суровом Челябинске задумались о переходе на УФ?

а чо бы нет?

(6) восьмёрка сырая :)

(7) ага :-)
И программистов хер найдешь.
одни "настройщики" и разносчики ИТС :-)

Mikeware стыдно не знать 8. в твоем-то возрасте

(9) Да как бы лень уже программить. Тем более, на 1С. Вообще, под толстого пишу, а вот нюансы с УФ (точнее, именно в 1c-овской реализации декларативного интерфейса).

(9) стыдно знать 8-ку и бомжевать

(11) вы так говорите, как будто это что-то плохое

Вообще-то задача (я так понял) озвучена:
хочу в первую очередь понять, "а не дурак ли я"

Предлагаю голосовалку.
1. Дурак.
2. Не дурак.
(0) чо сделать то хочешь?

кароче не взлетит, даже и не пытайся.
Там у тебя должен быть составной тип основным реквизитом, а динамический список такое не проглотит

заинтриговали..

давайте уже выкладывайте задачу то..

Mikeware в 7.7 я ее осуществлю легко

ээ, итоги в шапке?

(12) Тут не столько вопрос...
точнее, вопрос в том, насколько велик будет накладняк на эти действия...
-------------------
короче, идея такая: есть регистр правил - (способ хранения - РС или справочник - не суть важен)
структура: <вид документа><флагПриПроведении><ФлагПриЗаписи><ТекстЗапроса><ЧеловечьеОписание>
Цель: вынести проверки бизнес-правил из кода объектов, обеспечит управляемость "снаружи", понимаемость грамотными пользователями
Способ работы: при выполнении записи либо проведения выполняется запрос (проверка), которому передается объект. Если проверка "выполняется", "проходит" - запрос возвращает пустое значение.
Если проверка не проходит - запрос возвращает сообщение об ошибке. Соответсвенно, действие отменяется, а сообщение (сообщения, если их много) собираются, и выводятся пользователю.
-------------
собственно, вопрос: насколько велики будут накладные расходы на исполнение этого.

(19)это называется подписка на событие.
вешается 100% "сбоку" и работает без проблем..

я вообще не понял в чем проблема ЭТО реализовать?

Ну дык есть же метод Выполнить()

И причем тут УФ и ее тонкий клиент - вообще непонятно, все делается на сервере

(19) нормальная задача, я тоже думал о похожем варианте.

тут из УФ - только отрисовать РС на форме, а все остальное на сервере, как и подсказывают коллеги

Тут самый сложный момент - "понимаемость грамотными пользователями" - таких просто не существует! все равно будут звать программиста

сколько я видел параметризируемых конфигураций - ни одна не использовалась. документацию никто не пишет, в логике черт ногу сломит - легче открыть синтаксис помощник и прочитать

Собственно, возражения прогеров:
1) они не знают, в каком контексте будет выполняться запрос. пока писал - заставил проверить. Выполнить() выполняется в контексте вызова - может и на клиенте, и на сервере.
2) Пугают "тоннами кода".

(25) послушай программистов и даже не начинай это гиблое дело. если и найдется желающий покодить "пользователь" - от таких лучше держаться подальше

(25) там проблема еще и в том, что запросы в РС надо поддерживать при обновлениях.удалятся какие-то реквизиты, и проведение вывалится с ошибкой.
а если через через попытку, то получишь транзакцию в транзакции(проведение), что не есть хорошо

лекарство для подчиненных

(24) тут без программиста никуда. Ибо запрос юзверь не напишет. Писать будут только программисты.
понимаемость пользователями - в том смысле, что ГрамотныйЮзверь™ смотрит в книгу видит фигу в этот регисто, и видит,что "для документа ЗаказПоставщику" в момент записи проводится проверка называемая "проверить на значительное превышение остатка лимита", или "для документа ЗаявкаПокупателя" в момент проведения проводится проверка называемая "проверить на низкую наценку". Вообще говоря, там (в регистре) есть еще кое что "для пользователя", но на обработку это не вляет, поэтому я об этом умолчал...

Если юзвери сам код править не будут - так все карты в руки, подписки на события (обработки с проверками можно сделать хоть внешними) + регистр с настройками

Только это не режим УФ - все на сервере

Вообще клиент на УФ - это просто формочка в которую по запросу заливаются данные

(27) Естественно, поддерживать/контролировать код проверок при обновлениях - нужно. Это и так, и сяк делать нужно.

прикольно будет, если сделать спр, где хранить проверки "в человеческом виде".
типа "Проверять заполнение цен при проведении", "Проводит только ответственный", "Запрет проведения, если дата документа меньше более чем в 2 дня от текущей" и пр.

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

+(32)Хотя обновления для оперативной базы не очень и нужны. Вон, у меня торговля работает - она в девичестве 9.31 была. Почти ничего не "накатывали", ибо накатывать на базу в 24*7 (да еще и 140Г) трудно.
за 2 часа простоя оперативной работы я могу не только бонуса лишиться, но и части зарплаты..

Mikeware (да еще и 140Г

это у вас на 7-ке столько? солидно

(4) Короче, Склифосовский, что нужно сделать?

(37) Да. Ну и 85 пользователей, ОЛАПы всякие, бизнес-процессы, всякие восстановления последовательностей во время работы пользователей, открытие периода в разделеном режиме во время работы, и т.п.... т.е. по меньшей мере 21.5 имею :-)
правда, смотрел в свое время у Олега Садовникова конфу - там она под 300 была, но главное - управляла, допустим, движением тележек вот таких:

(19) ну нечто подобное мы делаем... компоновкой данных и хранением отборов для бизнес-условий.

(39) я даже боюсь оценить, сколько эти данные будут весить будучи в 8-ке УФ. минимум раз на 5 нужно умножить, имхо

(38) см (19)

(37) у меня на семерке было порядка 500 конкурирующих пользователей и база весом под полтеррабайта

(41) Я тоже этого боюсь. Хотя там говна много (аналитики, от которой уже отказались) - я как-то в мизде года 4 назад выкладывал снапшот кубика в 1С с 17 разрезами аналитики

(45) Короче компоновка Вам в помощь, как хранить отборы проблем особых нет

(47)Жень, а зачем компоновка? объясни полудереву, плз...
можно даже скайпом, чтоб по силы на надавливание клавиш не тратить

(19) Само получение кода из справочника или регистра будет очень быстрым.
А для выполнения этого кода существует команда "Выполнить".
Не вижу проблем.
Если только там нет сложных математических расчетов (заявлено, что Выполнить работает медленнее, чем обычный код в модулях).

(48) Отборы проще хранить, настраивать, можно даже периодические делать и т.п.
а объект скармливать в качестве параметра.

(52) (53) аська чой-то сдохла, а скайп - mikeware2007

(54) щас добавлю

(58) Это предусмотрено :-) а вот они его вывести не могут

А в чем глубинный смысл задачи? Зачем требуется бизнес-логику непременно вырвать из кода и запихнуть в базу? Работать по-любому такое решение будет медленнее. Раньше такое практиковали как эрзац глюкавого демонического обновления, там где нельзя было для нормального обновления выгонять юзеров. Сейчас демоническое достаточно надежно, смысла не вижу.

(39) 3.5 терабайта, правда 8.1

(60)с демоническим - натыкались на косяки совсем недавно, в конце прошлого месяца. Да и вообще периодически требует очистки кэша. в 7.7 с этим проще. "восьмерка сырая"© :-)

(62) Глюки кэша в 8-ке это фигня. Страшно было когда демоническое убивало базу.

(63) По опыту поддержки такой конфы:

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

Для программера монопениссуально где смотреть код, в конфе или справочнике алгоритмов. Но чем больше возможных мест хранения логики тем больше гимора с раскопками. Юзеры в код бизнес-логики лезть не будут все равно, независимо от места его хранения. Для них это темный лес.

частично - рулить (включать-отключать).

Ага, проще. Кто-то снял галку - начались танцы у юзеров. Мне было с этим легче, я был единственный одинэсник, но все равно проблемы случались. Если у тебя больший штат - проблемы вида "кто бросил валенок на пульт кто отжал галку" гарантированы.

частично - чтоб обновлять проще.

На самом деле не проще. При нормальном обновлении ты видишь что и как меняется, можешь понять последствия. Когда у тебя в справочнике лежит код, единственный способ узнать его работоспособность после обновления - пробежаться по граблям. Автоматической проверки валидности нет. Даже тупейшего синтакс-чека не сделаешь.

и еще несколько пунктов.
то, что медленнее - это понятно. вопрос - насколько медленнее.

Насколько медленнее за глаза сказать нельзя. Смотря какой код вынесен в справочник. Тормоза возникают из-за дополнительного обращения к базе для чтения кода алгоритма и компиляции. В подотчетной базе тормоза были заметны даже на глаз, что вынудило разрабов изобретать механизмы кэширования для хранимых алгоритмов. Решение несколько повысило быстродействие, но взамен принесло новые глюки кэша.

Короче говоря, мое мнение - нах такое решение. Никакой пользы кроме вреда не получается.

(0) знакомый ник. Ты случаем в IRC #1C не тусил?

ТеньД (62) Глюки кэша в 8-ке это фигня. Страшно было когда демоническое убивало базу.

ну, фигня-не фигня, но когда оно у четырех разных людей в одном кабинете работает по-разному....

Для программера монопениссуально где смотреть код, в конфе или справочнике алгоритмов. Но чем больше возможных мест хранения логики тем больше гимора с раскопками. Юзеры в код бизнес-логики лезть не будут все равно, независимо от места его хранения. Для них это темный лес.

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

Ага, проще. Кто-то снял галку - начались танцы у юзеров. Мне было с этим легче, я был единственный одинэсник, но все равно проблемы случались. Если у тебя больший штат - проблемы вида "кто бросил валенок на пульт кто отжал галку" гарантированы.

"Кто-то" не снимет. Есличо, у меня в 7.7 самые большие таблицы - это логи действий.

На самом деле не проще. При нормальном обновлении ты видишь что и как меняется, можешь понять последствия. Когда у тебя в справочнике лежит код, единственный способ узнать его работоспособность после обновления - пробежаться по граблям. Автоматической проверки валидности нет. Даже тупейшего синтакс-чека не сделаешь.

мысли, как это тестировать - тоже есть.

Насколько медленнее за глаза сказать нельзя. Смотря какой код вынесен в справочник. Тормоза возникают из-за дополнительного обращения к базе для чтения кода алгоритма и компиляции. В подотчетной базе тормоза были заметны даже на глаз, что вынудило разрабов изобретать механизмы кэширования для хранимых алгоритмов. Решение несколько повысило быстродействие, но взамен принесло новые глюки кэша.

на худой конец, перенести эти проверки непосредственно в код - дело нескольких часов.

Короче говоря, мое мнение - нах такое решение. Никакой пользы кроме вреда не получается.

у каждого свои тараканы. ваше мнение - услышал. спасибо.

(67) а, ну тогда забей)

(0) а почему вы себя так ограничиваете одним запросом. Почему бы при проведении документа не выполнять произвольный метод в произвольном месте?
у нас так сделано (насколько я могу себе представить аналогию с SAP/ABAP)

(69) Не совсем понял про "произвольный метод в произвольном месте".
если про то, что хочу выполнять не произвольный код, а произвольный запрос - на мой взгляд, накладняк на компиляцию кода несколько выше накладняка на план запроса.
но в конце концов, непринципиально. можно и код. Но в восьмерке практически все хотелки (в части проверок) можно реализовать запросом

(71) ну просто по моему куда проще писать/отлаживать/тестировать в каком нибудь глобальном модуле процедуру чем запрос. И к тому же, если у вас в дальнейшем появятся какие нибудь проверки, которые запросом не сделать, у вас уже будет рабочий фрэймворк которые будет такое требование воспринять. А просто впихнуть запрос в процедуру и выполнять его там - не такие уже большие накладные расходы по сравнению с выполнением одного запроса. Опять таки, я не знаю, есть у вас тестовая система или нет - но версионировать код (хранилище конфигурации) куда проще, чем запросы в справочнике.

(72) Кстати да, про этот минус я забыл. Алгоритмы в справочниках придется версионировать отдельно от остальной конфы.

(19) Сделаю почти даром - 12 тыс руб )

вопрос: на сколько эти "вынесенные" модули будет просто и доступно отлаживать???
вот прог, который будет в дальнейшем поддерживать эту конфу, возрадуется

моё ИМХО так делать не стоит!!!

(75) а в чем проблема то? прог увидит, что при проведении читается какой то регистр и оттуда берется имя процедуры/модуля, которую надо вызвать. Ну и все.
Если уж совсем правильно сделать, то можно написать простенькую внешнюю обработку в которой эти модули статически вызывать в зависимости от документа и отлаживать себе на здоровье

(76)а как ты будешь отлаживать модуль в "обёртке выполнить"???

ЗлобнийМальчик Если уж совсем правильно сделать, то можно написать простенькую внешнюю обработку в которой эти модули статически вызывать в зависимости от документа и отлаживать себе на здоровье

(77) три минуты работы

(74) Почти сделал уже. По крайней мере, практически доказано, что реализация возможна. после праздников отдам на доработку.
(75) Поддерживать буду, грубо говоря, я. Именно для того, чтобы поддерживать - так и делаю.
Ибо поддержка "кода" уже достала.
(76)+1
(79)"за неимением горничной имеют дворника"©

просто не пойму в чем тайный смысл?
лень открыть конфигуратор и православно написать код? писать удобно, проверить сразу синтаксис
отладить на тестовой, протестировать, создать релиз, и забыть ...

(81) динамически подставляем проверки без изменения кода проведения. достаточно частое требование честно говоря.
Дык в таком фрэймворке этот код так и пишется - православно и в конфигураторе

(82) Дело не столько в динамическом изменении (оно, конечно, хорошо - но не критично), сколько в то, что бизнес-пользователи знают и понимают, какие у них сейчас проверки есть, какая у них реакция на "непрохождение". а пользователям уровня исполнителя - корректно понятны необходимые реакции на ошибки.

(83)толково созданное вокфлоу прямыми руками решает это проблемму

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

(83) ну теоретически вы могли бы эти проверки с тем же успехом зафигачить прямо в проведение... Так что с моей точки зрения основное преимуществл - именно динамическое исполнение. Но просто в сапе дотащить разработку до продуктивной системы обычно - тот еще геморрой. Мы вот практикем обновление продуктива каждые три месяца - а есть добрые люди которые раз в пол год перетаскивают...

(86) естественно, могли. и сейчас все еще можем :-) или могём?:-))
другое дело, что понимать, какие именно проверки сейчас имеются (хотя бы заявлены, задекларированы) - без лазанья в код возможности нет. Даже в коде - проверки не совсем явные. Т.е задайте себе вопрос: "какие проверки у меня в системе есть при записи и при поведении", и зафиксируйте - где, как и сколько по времени вы ищете ответ.

(87)вопрос зачем?
возникла ошибка проверки, толковое разъяснение с указанием рквизита, всегда хватало

(88) Еще раз повторяю. представь себе, что тебя вызывает, допустим, гендир (коммерческий, дир по продажам, фин или еще кто - не суть важно, но уполномоченый задавать вопросы.) И спрашивает: "какие проверки в системе есть при записи и при поведении".
ответь......

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

Хренассе.... бизнес-пользователям (читай - заказчикам ми работодателям), значит, должно быть фиолетово, и их слать лесом? :-)
встречный вопрос: "а служба ИТ, часом, не уху ела?"

x86 ИТдир такой вопрос может задать, ему толково объяснишь что смысла описывать нету

ага. ну тогда я б толково объяснил, что смысла платить такому сотруднику зарплату - нет....

(91)еще раз повторю: не уровень ген дира следить за крыжиками, этож очевидно
допущу, что в каком-нибудь ларьке, где ген дир сам себе и сват и брат такое может быть, но мы же не про этот случай?

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

(93)>>"по условиям ценового соглашения на продукцию этого произвдителя нам запрещено давать скидки при торговле в этом регионе" - это реализовано?
на это вопрос ответить проще простого

ген дир задаст тебе вопрос: "пока жи все проверки"
ты: вывалишь ему отчет из 200-400х доков/справочников, у которых по 30-80 условий проверки (причем условия проверки будут пестец многоэтажные)
вопрос: что он будет делать с этим отчетом? в чем его полезность? а не надуманна ситуация?

(94) я ж тебе конкретный пример привел.
зададут тебе такой вопрос - сколько времени надо, чтоб ответить?

(96)как уже говорил пользователю важен вокфлоу, а не ограничения

Задача осуществима - но писать код в режиме предприятия - зло. Ибо не поддается отладъке совершенно