зачем 1с сделала выполнение кода на клиенте в УФ? #714947

простой вопрос который ставит меня в тупик: зачем 1с сделала выполнение кода на клиенте в УФ? почему 1с не пошло по пути RDP, когда на клиенте идет только отображение без выполнение скриптов?

простой вопрос который ставит меня в тупик: зачем 1с сделала выполнение кода на клиенте в УФ? почему 1с не пошло по пути RDP, когда на клиенте идет только отображение без выполнение скриптов?

простой вопрос который ставит меня в тупик: зачем 1с сделала выполнение кода на клиенте в УФ? почему 1с не пошло по пути RDP, когда на клиенте идет только отображение без выполнение скриптов?

простой вопрос который ставит меня в тупик: зачем 1с сделала выполнение кода на клиенте в УФ? почему 1с не пошло по пути RDP, когда на клиенте идет только отображение без выполнение скриптов?

простой вопрос который ставит меня в тупик: зачем 1с сделала выполнение кода на клиенте в УФ? почему 1с не пошло по пути RDP, когда на клиенте идет только отображение без выполнение скриптов?

простой вопрос который ставит меня в тупик: зачем 1с сделала выполнение кода на клиенте в УФ? почему 1с не пошло по пути RDP, когда на клиенте идет только отображение без выполнение скриптов?

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

потому что клиент-сервер.

о, вечная тема

Хм.... Интересно, а как ты по рдп сделаешь веб-клиента?

вчера в БП 3.0 бух словила глюк в документе Поступление на расчётный счёт, и мне пришлось попрыгать по отладчику в обработке проведения... скажу честно: желание изучать УФ нет! я прошёл более 50 модулей и больше половины с одной строчкой. такое удручает

видимо, ради веб-клиента

очень просто, на основе ява аплета, так все клиент банки работают....

Ява?? Да ну её в такую дыру... Куда макар телят пастись не гонял....

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

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

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

>>веб клиенты сапа, навижена, диасофта, лотоса и т.д. ну 1с же потом и засунет свою УФ в " в такую дыру... Куда макар телят пастись не гонял...."

это готовые, законченные процедуры, не требующие отладки. Все остальное - осталось бы на долю реализации алгоритма 1С.

В УФ - тоже законченные процедуры, не требующие отладки (с) И чем это отличается?

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

Так и надо писать по теории.

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

УФ - размазывание каши по пустой тарелке. И каши нет (разделения и реальной эффективности клиент-сервера), и тарелка грязная.

1С беспощадно подсаживают на свою иглу...

нуну

Ещё один умник....

Да, этот так. Но не вчера произошло.

RDP так и работает, 100% реакторов обрабатываются на сервере, в чем проблемма?

умник, извольте не согласится, - это вы. Многим уже по выходу УФ была ясна бесперспективность и даже глупость такого подхода.

знаю. пойду кольнусь)

Рдп работает совершенно по другому принципу, если чо.

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

зато теперь у нас есть тонкий клитент, который тонкий только из 1С, но не для выполнения кода; веб-клиент, который и не вебклиент (не поддерживает веб-протоколы и технологии), а еще одна разновидность 1с-тонкого клиента на http.

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

*УФ нравится само по себе

Что интересно, я пока сталкивался с конфами на УФ (УТ, БП) только в файловом варианте. Это небольшие конторы, сервер никто не ставит себе. То есть преимуществ никаких, и все ужасно тормозит.

ИМХО, ради масштабируемости решений. Да, на маленьких нагрузках теряется производительность, но при росте сначала выравнивается, а потом обгоняет. В теории. На практике покажут реальные внедрения ERP 2.0. И типовые совершенно не показатель. Слишком уж много старой логики осталось, не оптимизированной под УФ. Этот как с запросами в ЗУП, которые писались до ввода ВТ и не переписывались после.

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

по любому принципу нужно было делать "УФ" отдельно, и только для упертых маньяков. А не строить на этом "новую концепцию платформы". И по какому "другому принципу" работает RDP? Работа RDP на клиенте не сказывается никак.

До этого они додумаются не раньше 1С 9.0

ради масштабируемости? ты хочешь сказать, что клиент банкинг обладает плохой масштабируемостью? простой пример i-bank на 1000 открытых сесий нормально крутится на 8 летнем сервере с 8 гигами оперативки..... ну-ка а для 1с например бух 3.0 на 1000 активных пользователей какое железо надо?

>>ради масштабируемости решений где в тормозах передачи данных с формы на сервер и обратно, в диких отборах ДС - масштабируемость? >> На практике покажут реальные внедрения ERP 2.0. в ларьках? на производстве это чудо не нужно. Или как с "отечественными" авто - все, что собрали корейцы в России - отечественное (в 1С - упаковка в картон, значит производство)? >>Слишком уж много старой логики осталось ну попробуйте старую конфу запустить на УФ. Со старой логикой. >>Этот как с запросами в ЗУП, которые писались до ввода ВТ и не переписывались после. - если бы был реальный эффект от перехода на ВТ, их давно бы переписали. А прирост на 2% в одном, и падение на 10% в дургом - не выход.

как вы представляете работу с файловой системой локального ПК, с софтом и драйверами, установленными на нем?

ИМХО, несравнимые по сложности задачи.

так-же как и RDP путем проброса портов

>>с файловой системой локального ПК, с софтом и драйверами 1с уже работает на уровне "с файловой системой локального ПК, с софтом и драйверами"? не заметил.

в чем несравнимость? 1 пользователь в бухгалтерии делает более большие селекты чем в клиент банке??? да и не забываем, что маштабируемость по размерам базы - это задача субд а не 1с...

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

>>что маштабируемость по размерам базы - это задача субд а не 1с - а что, на мисте уже все поняли, что 1С это не СУБД? не заметил ))

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

А что, какая-то особая религия запрещает запускать 1С по RDP? Раз уж ты такой любитель RDP, то и работай по нему.

>>так-же как и RDP путем проброса портов зачем 1с-у эмуляция интерфейса?! Да и не справится она с этой задачей. БД вон никак не может обработать...

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

а также подумай на досуге как работает СКД и прочая постобработка запросов. и как весело будет серверу, когда это все на него ляжет.

т.е. писать на УФ, чтобы потом запускать на rdp? Это новая концепция?

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

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

Т.е. я в сеансе РДП могу работать с файлами Excel, не имея его на сервере, а лишь на клиенте? >>где в тормозах передачи данных с формы на сервер и обратно, в диких отборах ДС - масштабируемость? при росте нагрузке на порядки они как тормозили, так и будут тормозить. В тот момент как старый принцип уже захлебнется и испустит дух. >>ну попробуйте старую конфу запустить на УФ. Со старой логикой. Как то превратно вы меня поняли. >>- если бы был реальный эффект от перехода на ВТ, их давно бы переписали. А прирост на 2% в одном, и падение на 10% в дургом - не выход. переписать ЗУП из гуманистических побуждений? Не смешите.

>>а также подумай на досуге как работает СКД и прочая постобработка запросов - а сделать "СКД и прочая постобработка запросов" на уровне платформы слабо? с выводом "наверх" точек входа инструкций программисту?

может ты не заметил, но 100% отчетов сейчас выполняет сервер в регламентных заданиях

Нагрузка идет не только на СУБД. Сервер 1С жрет тоже немеряно ресурсов.

А они и так на сервере лежат. Для особо одаренных - на клиент пересылается только отображаемая часть табличного документа.

Да чё вы спорите? Надо разделить два тезиса: 1. Идея УФ здоровая, интересная и заслуживающая одобрения 2. Реализация в типовых конфах - кал, подрывающий доверие к УФ в целом.

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

о, почти тоже написал - я за 2

Главный минус текущей реализации УФ - это платформенные серверные вызовы, которые порой происходят абсолютно рандомно. Бесит аж.

+1

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

>>Реализация в типовых конфах она не возможна по-другому в данных рамках платформы. Поэтому тезис 1) вообще отпадает. >>при прямых руках можно и на УФ писать понятный код - а как насчет не просто понятного (это важно для программиста), а просто производительного адекватного исполнения кода?

это ты про ребят из фирмы "1С"?

>>поразительно, как много людей не могут освоить уф поразительно, как много людей думают, что освоили УФ. Не потрудясь првоерить, а как оно теперь работает.

а кто в теме - кто автор идеи УФ в 1С? кого укусила в ж0пу оса?

>> - а как насчет не просто понятного (это важно для программиста), а просто производительного адекватного исполнения кода? Легко. Только думать надо, не все справляются. Когда у тебя все вызовы контекстные при каждом чихе пользователя, то беда получается.

никогда не слышал что архитектура клиент-сервер против кода на клиенте...

если считать, что типовые, даже написанные с нуля, работают хуже типовых на ОФ - то и это тоже верно.

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

>>что архитектура клиент-сервер против кода на клиенте... добро пожаловать в реальность 1С....

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

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

от части) не то что бы, но что то в этом есть)

Архитектура клиент-севрер никогда не была против исполняемого кода на клиенте. Ты щас тут утверждаешь обратное

>>и знаний как правильно писать запросы, блокировки и всё такое - т.е. вы-то уже точно выучили и отработали это все, плюс "и всё такое"?

>>Архитектура клиент-севрер никогда не была против исполняемого кода на клиенте архитектура - нет, не была. Реализация от 1С - именно против.

я нет - у меня столько пользователей нет. от этого утверждение теряет истинность? или утверждение о том что можно писать понятный код на УФ?

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

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

теряет. >>о том что можно писать понятный код на УФ? можно и по-английски писать понятный код. Речь сейчас не об этом.

>>потому что для такого цирка я еще не проснулся - упаковка?

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

:) тоже стирал пару раз... чуствую что спорит с каждым не своим словом. ради самого спора ниочем.

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

чем он усложняет что? Где преступление то, объясни на пальцах.

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

Тебе не нравится клиент-серверный подход?

что а что а РДП пока намного эффективней. Слишком тяжелой код на УФ в типовых

>>Нормально написанная самописка на УФ спокойно будет держать 1000 юзеров онлайн. - выводить 1000 раз "hello word" от каждого пользователя?

Для тех, кто писал на php+js+html ничего принципиально нового в УФ не найдёт.

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

А без УФ не будет?