Не первый раз встречаю когда в обычном приложении используют УФ, например в торговле 10.3. Подскажите, пожалуйста, зачем это делается, в чем преимущества УФ в торговле 10.3 перед обычными формами?

(0) Просто писателям всея руси из селезнёвки лень писать один и тот же код под разные формы, вот и кочуют формы из ут 11 в ут 10 и розницу и ка

Чтоб потом переделывать легче было.
Ну и ковыряться с ОФ такое себе удовольствие.

а приимуществ нет, сплошные недостатки

(3) Охват УФ, открываемой в ОП, шире, чем у ОФ. Потому что ее можно и в УП открывать.
Так что ты гонишь)

Да начнется!!!)

Такое не нужно. Просто аффтары не хочут возвращаться на ОФ. Им ограниченность ганглия не позволяет.

(0) Как уже сказали - лень писателей.

Нихрена не угадали.УФ в режиме тонкого клиента в разы меньше инфо гоняет.

(8) Первый раз слышу чтобы УТ 10.3 в тонком клиенте могла работать

(9) Дополнения к УТ10.3 активно использую.Клиент сервер.Да, нужно постараться, и кода там несколько больше.

(10)Только причем здесь тонкий клиент?

(11) Ну хорошо,тогда УФ+тонкий клиент = профит.

Вот, хотя бы один здравомыслящий уже отметился в ветке )

К прочтению.
http://catalog.mista.ru/public/198766/

(0) зато запросто можно организовать работу в тонком и веб клиенте

(12)Тогда непонятно причем здесь УТ103. Я не слежу за актуальными ветками УТ10.3 ибо незачем. И тоже как и (9) первый раз слышу, что УТ10.3 вдруг научилась работать в режиме тонкого клиента, разворачивать лень. Последний раз когда я ее видел, модуль управляемого приложения там был пустой. Поэтому поверю на слово. УТ10.3 дописали, до состояния "может работать в режиме тонкого клиента" или ты открываешь управляемые формы в толстом клиенте и делаешь вид, что это тонкий клиент?

(8) Можно было бы посмеяться, но только грустно.

(16) "непонятно причем здесь УТ103" // Иногда лучше читать, чем писать. УТ 10.3 упомянута как пример, в общем случае есть куча подсистем навешиваемых на любую конфу и которые на УФ, что дает профит в виде возможности работы в подсистеме в тонком и веб-клиентах

можно и в тольстом клиенте. тот же динамический список

Ну причин несколько:
1) для самоубучения. Года идут, ОФ потихоньку отмирают, и раз бабахнет переход на УТ 11, и все ты за бортом.
2) молодежь не очень в ОФ умеет, туда загнать тяжеловато.

(18) >>Иногда лучше читать, чем писать.
Я тоже так считаю. Но ты по какой то причине пишешь вместо того, что бы читать

>>УТ 10.3 упомянута как пример, в общем случае
Может все таки стоит поднять глаза и прочить (0)? Автор спрашивает зачем УФ в приложении, которое запускается ТОЛЬКО в режиме толстого клиента?
При слове УФ у адептов УФ падает забрало на глаза и они начинают брызгая слюной убеждать всех в том какие они прекрасные. Хотя с ними никто вроде и не спорил.

Один только динамический список в УФ чего стоит.

Вот надо тебе вывести список собранный из разных мест да и раскрасить его. В УФ это делается 3 нажатиями кнопки мыши. В ОФ это пол дня работы и тонна кода.

(21) "ты по какой то причине пишешь вместо того, что бы читать" // Попрошу без инсинуаций.
"Может все таки стоит поднять глаза и прочить (0)?" // Тебе - конечно.
Во-первых, найди там слово "например", что подтверждает мои слова, которые ты же сам и процитировал.
Во-вторых, убедись что там нет ничего, подтверждающего твои слова "в приложении, которое запускается ТОЛЬКО в режиме толстого клиента". То, что ты так думаешь про УТ 10.3, конечно же не означает, что это так и есть.
Так что 2:0, пока ты сливаешь )

>> Попрошу без инсинуаций.
Ты первый начал

>>Во-первых, найди там слово "например"
Ну увидел и что? В качестве примера выбрано приложение которое запускается ТОЛЬКО в режиме толстого клиента.

>>Во-вторых, убедись что там нет ничего, подтверждающего твои слова "в приложении, которое запускается ТОЛЬКО в режиме толстого клиента".
Там нет ничего опровергающего. Иходи из того, что там написано. В качестве примера у нас ТОЛЬКО одно приложение и оно запускается "ТОЛЬКО в режиме толстого клиента" все остальное ты додумал сам. Можешь туда таким макаром вообще, что угодно приписать: УНФ, игру сапер из виндовс и еще что нибудь. Автор же написал слово "например" просто для фантазии открыт, добавляй, то, что удобно. Пофигу, что имел ввиду автор, главное не проиграть спор. Любой ценой. О хоспадя...

>>То, что ты так думаешь про УТ 10.3, конечно же не означает, что это так и есть.
Напиши, где я ошибаюсь, вместо того, чтобы язвить и передергивать.

>>Так что 2:0, пока ты сливаешь )
Я был не в курсе, что мы соревнуемся. Если тебе полегчает: ты прав.

"Напиши, где я ошибаюсь" // Думаю, твоя ошибка в том, что слишком много кривды в твоих сообщениях

(21) "убеждать всех в том какие они прекрасные. Хотя с ними никто вроде и не спорил." - я бы поспорил. Во большинстве ситуаций УФ дают только тормоза и неудобство работы.

+(26) я в первую очередь про формы списков.

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

(26) >>я бы поспорил
В рамках данного топика имелось ввиду. Так то это тема для отдельного срача

ОФ - это уже вчерашний день. Вполне понимаю нежелание разработчиков писать под ОФ, когда можно использовать прекрасные и совершенные УФ.

Отчеты на УФ одно удовольствие рисовать, я именно с этого начинал.
С какими-то частями можно будет работать через web.
Простые формы разрабатывать намного легче, быстрее и красивше (именно интерфейс имею в виду).
В общем, смысл такой, что если можно использовать УФ - выгоднее использовать УФ. И руку набиваешь (или не сбиваешь) и проще потом наработки в современные конфы переносить.

(27) Ты про какие тормоза в формах списков? При одинаковой функциональности не встречал тормозов в сравнении с ОФ. Используя сложные/кривые запросы динамических списков, сортировки по неиндексированным полям на больших периодах и прочие лайфхаки - да, можно получить великолепные тормоза.

(32) открой ЖР в какой-нибудь базе на пол террабайта и подивись :)

(33) Ты про новый формат ЖР? Только УФ каким боком тут? Не нравится - включи старый текстовый формат.

(34) Но, в ОФ-то летает :)

(33) Очень релевантный пример.
(27) Хотя, конечно, тонкий клиент гораздо более капризен в плане отзывчивости интерфейса. ОФ почти всегда максимально отзывчив. УФ при разного рода накладочках сразу начинает лаги ловить.

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

Что-то мне эта ветка напоминает сказку О рыбаке и рыбке :)

(35) Емнип, новый формат ЖР и на ОФ на редкость тормознутый. Пока не наложишь отбор - ещё вроде ничего. Но стоит наложить хоть один (не дай бог несколько) - то можно идти пить кофе :)

(39) Я вообще не понимаю идеи писать первичный лог напрямую в СУБД.
ИМХО, первичный лог обязан быть текстовым и биться на файлики по дням. Это дает максимальную надежность, скорость записи и позволяет легко настраивать ротацию логов. А вот если не хватает скорости/возможностей анализа - тогда уже поверх первичных логов прикручивается агрегатор с нужными фишками, как это на "большой земле" обычно и делается.
А в 1С решили скрестить ежа и ужа. Получилось не очень. Теоретически анализировать должно быстрее, но сиквел-лайт для больших объемов не шибко подходит. Плюс все прелести СУБД, начиная с того, что ротацию легко не настроить.

Хотя в 1С вполне нормально писать лог действий пользователя (не технический лог) напрямую во "взрослую" СУБД. Как некоторые и делают, чтобы не заморачиваться с двухступенчатой схемой.
В 8-ке просто сделали большую глупость. Есть же технический журнал. Нафига в обычный ЖР писать события всех транзакций??? Это же бред. В 7.7 нормально было. Плюс невозможно настроить удобную детализацию. В итоге получаем на порядки бОльшие размеры ЖР в сравнении с 7.7 на тех же документопотоках.

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

(42) Я тоже. Более подробная детализация ЖР возможна только на тестовых базах.

(32) Сделай просто справочник на несколько сотен тысяч записей, иерархический. ОФ - мгновенный переход по группам, мгновенное отображение списка. УФ - грусть, печать, тормоза.

(6) вообще плюсую. В топку обычные формы. Есть возможность использовать УФ - надо делать.

(44) На нескольких сотнях тестить лень, ради доказательства что в интернете кто-то неправ.
А на десятках никогда не тормозило.

(46) Еще бы оно на десятках тормозило :)

(44) Файловая база таки да... но зачем там справочник на сотни тысяч записей для просмотра?

(48) Открыл свою рабочую базу, SQL. Список реализаций (около 5 миллионов).
Обычная форма - жмем PgUp, листается с конца к началу так, что посчитать не успеваю, но около 7 страниц в секунду.
Управляемая форма (простой дин.список без произвольного запроса) - по 1-2 странице в секунду.

(49) УФ, БП3 клиент-сервер. Открыл список номенклатуры, в ней ~ 5 тыс элементов. Да и неважно сколько их.
Жму PgDown - страницы мелькают так, что не успеваю подсчитать.

ЧЯДНТ?

(49) Мой список реализаций (2 миллиона) листается только в путь. Не похоже, что медленнее 7 страниц в секунду.

(45) Что-то ты не туда плюсуешь) Там, где ты плюсуешь, утверждается, что УФ в ОП не нужны и те, кто делают так, делают это не от большого ума)

(49) "Управляемая форма (простой дин.список без произвольного запроса) - по 1-2 странице в секунду" // А в ОФ тоже дин. список листаешь?

(6) не могут?

(47) Что значит "еще бы"? Я, например, не могу себе представить по какой причине список не тормозящий на листании десятков тысяч записей должен начать тормозить как не в себя на сотнях.

(55) Ну если отключить динамическое считывание данных, то вполне себе может тормозить.

(53) В ОФ - ДокументСписок, а какие еще варианты?

(31) т.е. весь профит - в "прогрессивности"?

(57) ДС в ОФ

(0) Потому что это быстрее - можно сделать нормальную форму и не возиться с идиотскими привязками в ОФ.

(57) Значит надо смотреть, где задержка) Кажется проще сравнить для начала запросы очередной порции к СУБД (в профайлере, например) в ОП и УП. Если там разницы не будет, то уже сравнивать время передачи данных с сервера в форму.

(61) И что это даст? Имеем, что имеем: на одних и тех же данных ОФ - в разы быстрее.

(62) Может, дело именно в боках работы УФ на толстом клиенте. Не думаю, что в 1С этот режим вылизывали. Во всяком случае, я уже сталкивался с разного рода "шероховатостями".

(62) ОФ быстрее (с этим трудно спорить), но быстрее они так сказать "базовой" комплектации - взять тот же "ДокументСписок" - сам по себе работает быстро, а теперь давайте-ка разукрасим его, добавим рассчитываемые колонки и посмотрим... УФ удобнее (+больше возможностей), как в плане настройки так и в плане разработки (хотя тут конечно палка о двух концах)

(0) Я так постоянно делаю.
Причина простая. Есть монструозная конфигурация на ОФ. Перейти на УФ нельзя, внедрение займет годы и сотни миллионов рублей.
УФ используются для:
1. Переноса функционала из других конфигураций;
2. Удобных отчетов на СКД. В т.ч. внешних.;
3. Динамических списков.

Все новые модули мы разрабатываем на УФ, юзаем их через такси, но обращение к формам справочников и отчетов этих модулей возможно и в ОФ.
Некоторые функции БСП в режиме ОФ тоже используем.

(40) +100
Идея писать детализированный ЖР в sqllite - мудацкая.

(62) Так ведь вероятность немалая, что понимание места, дающего задержку, даст возможность ускорить дин. список в УФ.
То, так ты говоришь, аналогично ситуации, когда груженая камнями ламба не разгоняется за 3 секунды до 100 км/ч, и ты говоришь что заглядывать в багажник нет смысла )

(65) Стоп. А как ты умудряешься использовать внешние отчеты СКД на УФ в обычном приложении? Обычное приложение же вроде принципиально не хочет открывать УФ во внешних отчетах/обработках.

(66) Да, удивительно, как в 1С сами раскладывают себе грабли, а убирают только тогда, когда по лбу получают.

(67) А зачем 1С по-умолчанию в ламбу(УФ) камней наложила?
"места, дающего задержку" - задержку дают или запросы, которые 1С генерит к СУБД, или обработка этих запросов на сервере 1С, или перемещение кучи данных между клиентом и сервером. В любом случае - движок 1С не поменять. Можно пытаться шаманить и модифицировать запросы/формы так, чтобы 1С их проглатывала максимально легко, но - это затраты с непонятным результатом.
Каюсь, одну УФ в свою конфу встроил - для специфического документа, маркетинг хотел хитрые отборы и группировку в журналах.

мыши плачут, колются, но жрут кактус...

(71) Осталось только разобраться с вопросом, что является кактусом ОФ или УФ? :) или 1С в целом )

Думаю, в УТ 10, как и в УПП, управляемые формы появились, когда появилась 8.2 и тогда еще были планы перевести старые конфигурации на УФ.
А потом появились ERP и УТ и эти планы потеряли свой смысл.

(68) Предположу, что какие-то манипуляции с формой отчета, которую можно брать из конфигурации. Теоретически можно какую-то подсистему свою подсистему реализовать.

(68,74) Да, встроенная в конфу специальная форма. Для отчетов на СКД без формы.

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

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

(77) чем обработка оповещения лучше чем просто "Выполнить"

(71) А какая альтернатива? Утки?

(70) Почему по уолчанию? Вон (32) (50) и (51) пишут что все летает из коробки )

(72) я за то, что кактусом являются УФ.
я понимаю, что "дело привычки", "новая прогрессивная платформа" и все такое - но тормоза по запуску (БП3, УТ11 - ERP побоялся), медленная работа, ублюдочный интерфейс...

(80) "летает. но нызЭнько-нызЭнько..."©

(81) Ты предвзят. Я скажу так - у концепции толстого клиента (в принципе, а не в текущей его реализации) есть очевидные преимущества:
- отсутствие дополнительных прослоек (которые в частности могут приводить к лагам интерфейса)
- простота разработки (ибо моноприложение, что по сути смотри п.1)
Декларативный интерфейс могли бы вполне реализовать и в концепции толстого клиента. Как и множество других плюшек, которые сейчас есть в тонком клиенте. И была бы конфетка.
Но.
У тонкого клиента тоже есть очевидные преимущества. В том числе - трендовые (та же облачная 1С, например - новое направление продаж). Другое дело, что для многих покупателей они неважны. Но 1С пришлось выбирать, ибо тянуть параллельно по сути две продуктовые ветки - плохая бизнес-идея. Так как функционально тонкий клиент покрывает толстый - выбор был очевиден. Толстый клиент определили в дом престарелых доживать свои дни.
Поэтому теперь уже выбор стоит не между толстым клиентом и тонким, а между каменеющим артефактом и современным и развивающимся продуктом.
В этом моменте семерочники должны фыркнуть и сказать, что восьмерка - это испорченная семерка, которая была простая как три копейки, где все делалось в пол-пинка, ресурсов она не жрала, лицензии были бесконечные и пользователям ничего лучше этого и не надо было и она еще всех нас переживет.

(70) >>одну УФ в свою конфу встроил
таки да... прогресс не отменить
и кстати списки все в УФ я так подозреваю часто можно упростить (оставив только наименование у того же справочника номенклатуры например, или номер/дату/контрагента у реализации, без навешанных красивостей) и тогда сравнивать уже что быстрее

(83) видел недавно одну семерку ТиС кстати... юзеры говорят что на 8ку не хотят)

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

(86) Это всё, но через такое жэ, что только адепты УФ считают это нормальным.

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

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

(86) Удобный отбор по текущему значению колонки (как в ОФ) сделали в каком-то дремучем релизе (как и переход из объекта в список с позиционированием на объекте, чего тоже сразу в УФ не было).
Поиск по колонке - кнопка расширенного поиска (или просто Alt-F в колонке).
Что такое множественные отборы? По нескольким колонкам? Их очень удобно набрасывать через те же отборы по значениям колонок. Они совместно применяются и красиво отображаются. Сложные отборы делаются через настройки, которые по-дефолту выносятся в быстрые настройки (ведь динамические списки в УФ через СКД сделаны) и дальше пользователю с этим уже удобно работать.

Хотя поиск по колонке работает в УФ как отбор по частичному совпадению. Если хочется чтобы именно "перескочило", не скрывая остальные данные - такого вроде нет.

Да и вообще удобство работы с динамическими списками в актуальном Такси - это одна из киллер-фич.

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

и по любым комбинациям - в списке/не в списке/ в группе/равно/больше меньше и т.д

(93) разве в уф этого нельзя?

+ хочу в списке найти что-то по текстовому представлению (части строки)...

(95) в какой конфе есть пример ?

(93) Еще - настроить список.
Всё есть, даже больше возможностей чем в ОФ со сложными отборами. Но менее удобно чем было, стало "дальше"

(93)(94)(96) Я вроде про все написал уже...

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

(97) вроде это базовая фича списка в уф.
или ты что-то другое имеешь ввиду?

(97) В любой, где есть ДС.

во, раз тут знатоки уф, спрошу..
Как в в УФ, в табличной части документа, добавить текстовую колонку (как в обычной форме), которая , например, отображает Сред(Номенклатура.Наименование,3,5) ?

(96) Ищи, кто не даёт?

(103) можно, но чутка сложнее чем на ОФ

(103) Добавляешь колонку у реквизита формы, который соответствует ТЧ.

(105) и...пример есть?
обычная таб часть любого дока

(106) этого реквизита нет в тч, чего добавлять ?

(107) неожиданно, но на форме туда можно добавить "красную" колонку

(103) Как в ОФ работать не будет. Надо пересчитывать самому по каждой строке в доп-реквизите (ессно в доп-реквизите формы, не объекта).
Причины абсолютно прозрачны - снижение нагрузки на тонкого клиента и более предсказуемый профиль нагрузки.

https://i.imgur.com/VGFw0jT.png

Пример, кто-нибудь может написать ?

(112) как добавить или как заполнять? смотри типовые. практически везде есть

обычно метод называется

ЗаполнитьДобавленныеКолонкиТаблиц();


(112) Зачем? Чтобы убедить тебя, что это можно делать в УФ? Может, проще тебе ИТС почитать?

(83) "Так как функционально тонкий клиент покрывает толстый - выбор был очевиден" // Лол

(114) в ут11, есть что-то похожее ?

(117) есть конечно

(116) те моменты что не покрывает - они вам не нужны )))

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

(112) В УФ как в шапку, так и в ТЧ можно добавлять реквизиты, которые не реквизиты объекта ("синенькие"), а реквизиты формы ("красненькие"). В базу они не пишутся. Просто живут пока живет форма. И заполняешь их как угодно по подходящим событиям. А на элементы управления "красненькие" реквизиты биндятся точно также как и "синенькие".

(118) ага, спсб. погляжу , на досуге

(121) в шапку объекта вроде нельзя

(120) ок

(123) Так там они и смысла не имеют. Не очень корректно выразился, согласен. Просто реквизиты формы, не в шапку.