Отличный стрим! Наглядно показал эволюцию мысли разработчика. Я время провел с пользой. В своей самописке использую второй вариант, так как его легко проверить и пересобрать на коленке.
Илья! Большое спасибо за такой формат, делай почаще разбор типовых задач. Обычно от обучающих видео меня тошнит, а тут почти 2 часа на одном дыхании. Узнал кое что новое...
Решать текущие задачи или повторять уже решенные из практики и не бояться повторяться (мол была уже печатная форма и больше не надо). Если с десяток раз посмотреть как делается печатная форма например, то на одиннадцатый уже сам сможешь ее сделать. Если сам не знаешь можно попросить накидают задании для простых доработок, а час в день для развития канала со стримом (без отвлечении на чат) это немного.
Добрый день. На большом количестве штрихкодов конкатенация строк не есть хорошо - лучше использовать функцию СтрСоединить(, ) (почему - копайте мануал). Проверка ШтрихкодИтого = "" это плохо, лучше использовать функцию "ПустаяСтрока()" проверка на пустую строку.
да.. из-за конкатенации в цикле на "длинном пробеге" даже 1с бывает вылетать..переполнение памяти или что-то подобное пишет.. Если Илья учил Java там тоже есть спец методы класса String для обхода этой траблы
было интересно, спасибо, определенно продолжать формат, в следующем хотелось бы видеть про ПФ, самое мозговыносящее, но и здесь конечно 3ий вариант показался сложноватым
Илья, родной, Спасибо тебе КОСМИЧЕСКОЕ за интересный видос в моей любимой рубрике! Люто лайкую и даю тебе жирный сигнал что такие видосы ооочень интересны и нужны! Ставлю таймер до выхода нового ролика из этой рубрики. Гагарин верит в тебя!!!)))
Ух, какие токсичные люди в чате. Специалисты они может и хорошие, но общаться и работать с ними, наверное, тяжело. Высокомерие сквозит в каждом замечании.
лайфхак: запрос отработает быстрее если просто сделать соединение по номенклатуре. в реальности дофига штрих-кодов вряд ли будет когда-нибудь. получить все имеющиеся варианты для номенклатуры и потом заполнять по совпадающим. к чему я это..условия "в" очень слабое по производительности. Так что выбираем только номенклатуру.. левым соединением выбираем шк.. потом уже заполняем. похожее проверял на базах 400gb поверьте мне это самый быстрый вариант
Добавлю свои 5 копеек. Считается плохой практикой называть переменные именами стандартных функций языка 1С. Например, в конструкции "Для каждого Строка из ТЧ Цикл" лучше писать "Для каждого СтрокаТЧ из ТЧ Цикл". Про запятые в перечислении ключей структуры тоже есть мнение - лучше один раз запомнить, что после каждой запятой следует пробел, чем то, в каких случаях его ставить, а в каких нет. Но в целом, спасибо за труд. Для новичков очень полезный контент.
сколько людей столько и мнений, я бы на сервер передал массив структуры без контекста, в ответ получил таблицу... вообщем тут не может быть верного решения, кроме первого, даже с кешированием! спасибо интересно было посмотреть, теперича давай разборы билетов по спецу клепай, только не забудь их в отдельный плейлист
Когда у специалиста есть понимание компиляций, передачи ТЗ через временное хранилище, решение занимает столько же время, как и во втором способе. Поэтому запрос в цикле и являться ошибкой.
Вот прикол был когда камеру на монитор не переставили. )) Вертикальный разделитель не был рассмотрен - в процессе выполнения задачи, клиент решил что он ему не нужен... ))
Надо было объяснить, чтобы сделать запрос в основную базу из расширения не обязательно было добавлять объекты, в данном случае, регистр. Все будет прекрасно работать и без добавления. Вы это сделали только для удобства кодинга.
Илья, здравствуйте. Может вы знаете, где и как можно свободно приобрести комплект разработчика без этих доп.проверок (юр лицо + прохождение каких-то специальных курсов)?
Попробуй заказать вот здесь: www.softmagazin.ru/1c/4601546046574/ Или здесь: www.online-ufa.ru/market/programmy-1s-predpriyatie/1c-komplekt-spetsialista-po-razrabotke-i-vnedreniyu/ Если все равно будут требовать покупку курса, покупай видеокурс за 2100 от УЦ1 )
Илья, вопрос немного не по теме, может ты уже где-то об этом курсе и говорил, что скажешь про курс ПРОФБУХ8 "Бухгалтерский и налоговый учет в 1С:Бухгалтерия 8 ред. 3 от А до Я"? стоит ли тратить время (там больше 100 часов)...?
Добавление элементов на форму при помощи редактора для меня равноценно удару серпом по тестикулам. Понятно, что это учебный пример, и основная тема вообще не о том. Илья, придерживаетесь ли Вы в своей регулярной практике концепции программной доработки типовых форм? Если да, то было бы интересно посмотреть стрим на эту тему. Спасибо.
@@bsnchita может на новых релизах с этим получше, но на 14-15 платформе было нереальное количество проблем с добавленными интерактивно элементами. Не отображались без видимых причин. Или после добавления реквизита формы нельзя было редактировать его свойства, приходилось переоткрывать под другой версией платформы ради этого. С программным добавлением в принципе могут быть только две проблемы: а) в новом релизе убрали/переименовали типовую группу, в которую вы добавили свой элемент. б) элемент связан с типовым реквизитом, который убрали/переименовали. Обе ситуации относительно редкие. Но даже в этих случаях ошибки исправляются проще.
А я в подобных задачах в расширение формы не добавляю. Ибо это очень гемморно в том плане что добавляется куча всего в расширение ненужного и даже вредного. Есть общий модуль ПодключаемыеКоманды В нем например добавляю: &После("ПриСозданииНаСервере") Процедура ЗП_ПриСозданииНаСервере(Форма, ПараметрыРазмещения = Неопределено) Экспорт Если Форма.ИмяФормы = "Документ.РеализацияТоваровУслуг.Форма.ФормаСписка" Тогда Форма.Список.ТекстЗапроса = СтрЗаменить(Форма.Список.ТекстЗапроса,"ДокументРеализацияТоваровУслуг.ВидОперации КАК ВидОперации,","ДокументРеализацияТоваровУслуг.ВидОперации КАК ВидОперации,"+Символы.ПС+"ДокументРеализацияТоваровУслуг.ЗП_ЗаказПокупателя КАК ЗП_ЗаказПокупателя,"); ЭлементФормы = Форма.Элементы.Вставить("ЗП_ЗаказПокупателя",Тип("ПолеФормы"),Форма.Элементы.Список, Форма.Элементы.Контрагент); ЭлементФормы.ПутьКДанным = "Список.ЗП_ЗаказПокупателя"; ЭлементФормы.Вид = ВидПоляФормы.ПолеНадписи; КонецЕсли; КонецПроцедуры;
@@IlyaLeontyev На самом деле не особо, так как код копипастом делается (из ранее так же дописанного), а не пишется заново. Зато всякие обновления, что сильно меняют форму этот код никак не затрагивают. Чуть сложнее, когда надо кнопочку разместить или на событие что-то помесить, но и тут обычно выход есть.
В типовых конфигурациях расширение достаточно добавить два общих модуля "МодификацияКонфигурации..." Никаких объектов вместе с общим модулем в расширение добавлено не будет. Сама форма в расширении тоже не нужна.
Я как-то потестировал сложное условие, когда таблицы сравниваются в запросе по типу (Поле1, Поле2, Поле3) в () (в виртуальных таблицах БУ смотрел) и оказалось что работает всё это гораздо дольше чем просто условие по Поле1 в (), а остальные через соединение таблиц (полное). В моем случае я получал 62 счет обороты с условием (Субконто1, Субконто2) в (таб.Контрагент, таб.Договоры). И в данном случае, может я чего-то пропустил, но зачем в финальной обработке результатов столько вложенных Выборка.Выбрать(), если по сути алгоритм линейный. Ну и опять же я лично обычно обхожу именно ТЧ документа (просто потому что так понятнее) и заполняю её данными Таблицы в которую выгрузил результаты запроса и проиндексировав поля поиска.
Меня слегка переклинило на фоне подготовки к спецу по платформе ) Там постоянно используется проверка именно "В" ) Но там немного другая ситуация, поэтому соединение было бы более уместным здесь. Хотя, учитывая скорость выполнения финального алгоритма, можно, наверно, и не оптимизировать уже ничего. Все работает достаточно быстро и правильно ) Остальное - уже придирки. Вложенные циклы нужны для того, чтобы было удобно суммарный штрихкод вычислять. Итоги ведь в запросе. Не пойму, как по-другому сделать. Подскажешь? Вариант с обходом ТЧ документа на клиенте в файловой базе не дает никаких преимуществ в производительности по сравнению с вариантом №2 (с запросами в цикле, на минуточку). Заполнение на стороне сервера значительно быстрее. (Ради чего, спрашивается, запрос оптимизировали?)
@@IlyaLeontyev Для конкретной задачи и так сойдет. Просто запросы подобные не только в заполнялках используются, но при построении отчетов, а там объем данных может быть очень большой и соответственно приходится их оптимизировать. Условие (п1,п2,п3) В (у1,у2,у3) иногда получается выполняется значительно дольше чем п1 в (у1), где это условие в виде параметров виртуальной таблицы а далее просто соединение полное по всем полям. Обход всё равно делается на сервере, просто в твоем случае ты его в выборку запроса поместил, а я предпочитаю сначала сделать что-то типа ТЗ кэша ШК, а потом в нем уже искать перебирая строки чуть ниже. Просто код чуть логичнее получается, особенно когда запросы большие и кэшей таких несколько. Хотя в вашем конкретном случае быстрее думаю ваш вариант (на пару процентов), так как строки в документе одинаковые почти все. И ещё при оптимизации заметил, что поиск по ТЗ значительно быстрее работает если к ней добавлен индекс. Так же, раз речь зашла о производительности, более сложные запросы обычно на SQL версии работают быстрее, чем на файловой, но вот вызовы идут дольше, а потому разница между 1 и 3 и даже 2 и 3 вариантом на SQL и больших данных будет более ощутима. И всё таки лучше взять в привычку писать сложные конструкции сразу, чем простые с формулировкой и так сойдет, так сказать набивать руку. Говорят нынче спец по платформе сложно сдать, ибо платформа усложнилась. Сам-то в 2007 году получил.
Немного покоробило от "чисто программистского" подхода: "Я не уточнял зачем задача именно в такой постановке, хозяин - барин, говорит/платит - делаю". Консультант внутри меня негодует xDD Уже очень давно не подхожу к реализации "Тупо в лоб", всегда начинаю обсуждение задачи с вопроса "А зачем вам это нужно?". Считаю этот вариант безусловно верным, так как зачастую задача от изначальной постановки преобразуется просто до неузнаваемости. И именно на за это многие клиенты тебя и начинают ценить, так как кругозор клиента в плане возможных реализаций задачи очень узок, и кому как не нам помогать им в это тернистом пути? ))) Так тупо в лоб может работать только программист из команды, где до него с такими вопросами к клиенту уже отработали, и раз дошло до реализации, значит все аргументы не сработали, и действительно нужно делать именно так, не задавая других вопросов :) А в остальном - норм, молодой поросли полезно смотреть на развитие мысли и прогресс реализации задач. Про золотую середину между оптимальностью решения в плане производительности и удобства дальнейшего сопровождения - однозначно плюс, согласен.
Всегда контекст надо учитывать. В данном случае у клиента уже была печатная форма с штрихкодами. И ему дополнительно к этой печатной форме понадобилось сделать такую хитрую штуку. В данном случае добивать клиента вопросами "А зачем вам это?" бессмысленно - мне все равно было нечего предложить взамен ) Возможно, его интересовала возможность постоянно менять состав колонок в "печатной форме". И сделать это дешево.
@@IlyaLeontyev Но нужно об этом долбить и долбить новичкам, каждый раз упоминать, проговаривать, иначе не по тому пути могут пойти ) В самом видео упустил, видимо, тот момент где задавался контекст. Если у клиента уже была печатная форма со штрихкодами, то да, изначальный помысел тем более интересен =)) Но все таки меня клиенты ценят как раз за то, что я их задолблю уточняющими вопросами, и добьюсь прояснения в их сознании =)) И мне спокойней - не делать в лоб, будучи просто инструментом, а помогать клиенту развиваться.
За нее разумно выставлять от одного до двух часов. Оценка зависит от того, каким способом в итоге задача была решена, и как много времени ушло на взаимодействие с клиентом. В некоторых тяжелых случаях (когда клиент не может нормально объяснить, что он хочет) можно и три выставлять. Сколько выставил конкретно я, пожалуй, оставлю в тайне :)
Направление правильное. За решение реальных задач плюсую. Но стиль Чистова как по мне устаревший. Ни кому не нужное общение со зрителями (малой частью подписчиков которым было удобно прийти на трансляцию) при чем не всегда по теме. Всегда есть шанс что тебя собьют, что то забудешь или что то пойдет не по плану (как например не правильно показанная сцена). Лучше записать видео и выложить его. Ни чего не будет забыто из того что запланировано. И можно расставить временные метки. Сейчас на ютубе это в роликах много кто стал практиковать (разбить например так: введение и постановка задачи, вариант 1, вариант 2, вариант 3, заключение). Если есть желание пообщаться , то запланировать показ отснятого ролика и потом сделать стрим с обсуждением. Это для случая как этот когда задача уже решена по сути. Раз в две недели это для развития канала мало. Таких маленьких задач уверен много и их решение можно на стриме как раз и решать (онлайн так сказать). Оптимальный формат "каждый день новое видео" если это показ работы разумеется, а не поговорить.
@@mrspacer1 Да на фига такое делать то? Я делал для УТ 11 так. У номенклатуры есть основное изображение. На его основе формируются миниатюры под высоту строки табличной части. Все это делается на лету. Если миниатюры еще нет, то она автоматом создается. Т.е. у номенклатуры получается в итоге несколько изображений. Ну а в списке номенклатуры и тч документов колонка с картинкой создается программно.
На стриме показали как делать НЕ НАДО! 1-2 способ, так могут написать ребята, которые только начали свою работу с 1с. А 3 вариант, что в итоге? Было получено условие с подзапросом и 3 вложенных цикла, а допустим нам нужно получить данные по 7 измерениям и что будет 7 вложенных циклов? Через левое соединение запрос отработает в 2 раза быстрее. Я не заметил запретил ли ты редактирование колонки со штрихкодами или очищаешь эти поля, ведь пользователь обновляет поля для которых заведен в базе штрихкод, 99% процентов, что заказчик снова обратиться :) Зачем при написании запроса в расширении тащить все объекты, ведь можно Запрос вызвать через Шаблоны текста? Дам совет не храните данные в расширении, и держите там как можно меньше объектов, лучше убедить заказчика включить возможность вносить изменения в конфигурацию. А вообще эту задачу уже решили, есть же отчет. Почему ты не можешь вызвать конструктор СКД и не добавить макет туда? Вот пример решение через СКД, кстати так эту задачу тоже решать не надо, но для примера того, что я написал можно показать. В товары нужно добавить колонку "Штрихкоды" yadi.sk/d/hVvY4wBGWV_bvg
Если вы считаете что третий вариант такой уж и плохой, то что предлагаете?) а то это так выходит все тут неправильно сделал автор. Критикуеш - предлогай) Вы писали за левое соединение, а зачем делать именно левое соединение если у нас допустим 100 товаров а штрихкод есть у одного товара) может уже тогда лучше сделать внутреннее соединение и связь тройную, но от куда вы увереннее что оно прям в два раза будет быстрее) я думаю оно будет так же а запрос будет еще длиннее. И о каких шаблонах текста идет речь? Если о конструкторе во внешней обработке, то смотрите второй стрим - там это разжевывалось.
@@maxim.saharov , Я конечно прочитал ваш комментарий, хотя видео было выложено почти пол года назад. Абсолютно верно, левое соединение отработает быстрее, я провел замеры скорости выполнения. Так же я написал обработку и приложил ее к комментарию, которая соответствует первоначальному условию задачи я думаю моё предложение достаточное, а не просто слова в воздух. По второму вашему вопросу, автор ролика насколько я помню решал через расширение. В расширение при вызове Конструктора запроса нет доступа к объектам, которые не были добавлены в расширении и автор делал странный финт добавляя множество объектов в расширении, хотя не имея на это надобности. Большинство людей уже заметило, что при разработке через расширение удобно использовать СЕРВИС - ШАБЛОНЫ ТЕКСТА - СТАНДАРТНЫЕ - ПРОЧЕЕ - ЗАПРОС . При перемещении запроса в редактор у вас открывается доступ ко всем объектам, очень удобно. Максим можете скинуть ссылку на второй стрим где вся эта бездарность разжевывается? В комментарии я указал, что у меня не идеальное решение, кто знает тот поймет.
Просто надоело. Просматриваю "уроки" от разных авторов (без указания цели, для чего мне это нужно, после 20 лет работы с 1С). Но чем грешат ВСЕ авторы . И не глупые (вроде) люди, но ЗАЧЕМ убивать свое и чужое время на рассказ о том как делать неправильно? Поверьте, неправильно сделать (и гораздо более "неправильнее") все, вас смотрящие, могут и сами. Поэтому просьба: Не занимайтесь херней. Ставлю жирный дизлайк.
![Quando Rondo - Life Goes On [Official Music Video]](http://i.ytimg.com/vi/eIf3fhMXAow/mqdefault.jpg)
Отличный стрим! Наглядно показал эволюцию мысли разработчика. Я время провел с пользой. В своей самописке использую второй вариант, так как его легко проверить и пересобрать на коленке.
Илья! Большое спасибо за такой формат, делай почаще разбор типовых задач. Обычно от обучающих видео меня тошнит, а тут почти 2 часа на одном дыхании. Узнал кое что новое...
Решать текущие задачи или повторять уже решенные из практики и не бояться повторяться (мол была уже печатная форма и больше не надо). Если с десяток раз посмотреть как делается печатная форма например, то на одиннадцатый уже сам сможешь ее сделать.
Если сам не знаешь можно попросить накидают задании для простых доработок, а час в день для развития канала со стримом (без отвлечении на чат) это немного.
Ждем еще стримов с решением задач! Было познавательно.
Добрый день. На большом количестве штрихкодов конкатенация строк не есть хорошо - лучше использовать функцию СтрСоединить(, ) (почему - копайте мануал). Проверка ШтрихкодИтого = "" это плохо, лучше использовать функцию "ПустаяСтрока()" проверка на пустую строку.
да.. из-за конкатенации в цикле на "длинном пробеге" даже 1с бывает вылетать..переполнение памяти или что-то подобное пишет.. Если Илья учил Java там тоже есть спец методы класса String для обхода этой траблы
А чем плох вариант сравнения с ""?
@@bsnchitaits.1c.ru/db/metod8dev/content/2614/hdoc&ved=2ahUKEwiQ0JzJysztAhVhl4sKHQjfCTIQFjAAegQIARAB&usg=AOvVaw2HL6QkoCtl2m_dP6COz-bW
Илья очень позитивный человек)
Огромное спасибо тебе, Илья, за твой титанический труд!!!
Спасибо большое, всегда очень полезно и интересно 😊
было интересно, спасибо, определенно продолжать формат, в следующем хотелось бы видеть про ПФ, самое мозговыносящее, но и здесь конечно 3ий вариант показался сложноватым
Все четко показал! Спасибо
Чётко! Давай ещё!
Спасибо!
Спасибо. Супер, продолжение будет?
До конца кода будем готовиться к спецу по платформе. А там видно будет )
Супер! Нужен стрим или урок по использованию консоли запросов и конструктора запросов!
Про запросы IRONSKILLS классные видео записали:
ruclips.net/video/IN6Zb75OnqU/видео.html
ruclips.net/video/bl5PsQNzFHc/видео.html
Ох, великолепные выводы))
Илья, родной, Спасибо тебе КОСМИЧЕСКОЕ за интересный видос в моей любимой рубрике!
Люто лайкую и даю тебе жирный сигнал что такие видосы ооочень интересны и нужны!
Ставлю таймер до выхода нового ролика из этой рубрики. Гагарин верит в тебя!!!)))
спасибо, продолжайте, пожалуйста подобные темы :)
Спасибо за видео!
Спасибо за видео! Ты крутой программист
еще хотим
Ух, какие токсичные люди в чате.
Специалисты они может и хорошие, но общаться и работать с ними, наверное, тяжело.
Высокомерие сквозит в каждом замечании.
лайфхак: запрос отработает быстрее если просто сделать соединение по номенклатуре. в реальности дофига штрих-кодов вряд ли будет когда-нибудь. получить все имеющиеся варианты для номенклатуры и потом заполнять по совпадающим. к чему я это..условия "в" очень слабое по производительности. Так что выбираем только номенклатуру.. левым соединением выбираем шк.. потом уже заполняем. похожее проверял на базах 400gb поверьте мне это самый быстрый вариант
Дополнительно - не забудьте добавить индекс по полям соединения во временной таблице, производительность ещё больше увеличиться
@@ДмитрийГречушкин-ю1ъ, только на больших выборках, на малых не будет разницы.
@@Anton-ni8un согласен полностью - на меленьких небольшая просадка по времени на создание индекса (но она совсем незначительная)
Добавлю свои 5 копеек. Считается плохой практикой называть переменные именами стандартных функций языка 1С. Например, в конструкции "Для каждого Строка из ТЧ Цикл" лучше писать "Для каждого СтрокаТЧ из ТЧ Цикл". Про запятые в перечислении ключей структуры тоже есть мнение - лучше один раз запомнить, что после каждой запятой следует пробел, чем то, в каких случаях его ставить, а в каких нет. Но в целом, спасибо за труд. Для новичков очень полезный контент.
сколько людей столько и мнений, я бы на сервер передал массив структуры без контекста, в ответ получил таблицу... вообщем тут не может быть верного решения, кроме первого, даже с кешированием! спасибо интересно было посмотреть, теперича давай разборы билетов по спецу клепай, только не забудь их в отдельный плейлист
Весьма полезно!
Когда у специалиста есть понимание компиляций, передачи ТЗ через временное хранилище, решение занимает столько же время, как и во втором способе. Поэтому запрос в цикле и являться ошибкой.
Вот прикол был когда камеру на монитор не переставили. )) Вертикальный разделитель не был рассмотрен - в процессе выполнения задачи, клиент решил что он ему не нужен... ))
Илюха классный стрим, очень понравился, а на холиваров не обращай внимания, они говорят и ничего не делают!
Надо было объяснить, чтобы сделать запрос в основную базу из расширения не обязательно было добавлять объекты, в данном случае, регистр. Все будет прекрасно работать и без добавления. Вы это сделали только для удобства кодинга.
Илья, По наитию всегда использовал 2 вариант )) Спасибо за Вариант номер 3 ))). Спеца по платформе нет, если что )))
Приходи тогда на стримы по подготовке к спецу )
ruclips.net/p/PLh28ogpgRJUPQDnx1uV9p19jLbpyBa3ua
Илья, здравствуйте. Может вы знаете, где и как можно свободно приобрести комплект разработчика без этих доп.проверок (юр лицо + прохождение каких-то специальных курсов)?
Попробуй заказать вот здесь: www.softmagazin.ru/1c/4601546046574/
Или здесь: www.online-ufa.ru/market/programmy-1s-predpriyatie/1c-komplekt-spetsialista-po-razrabotke-i-vnedreniyu/
Если все равно будут требовать покупку курса, покупай видеокурс за 2100 от УЦ1 )
@@IlyaLeontyev Спасибо. Отказали((
ИЛЬЯ ЭТИ ОЧКИ ОДЕВАЕШЬ ДЛЯ ЗАЩИТЫ ОТ БЛИКОВ ОТ МОНИТОРА ? ИЛИ КОГДА ОПАЗДЫВЕШЬ НА СТРИМ?)))
Эти очки - фишка формата реальных задач )
Типа это очень круто - решать реальные задачи вместо рафинированных примеров.
Илья, вопрос немного не по теме, может ты уже где-то об этом курсе и говорил, что скажешь про курс ПРОФБУХ8 "Бухгалтерский и налоговый учет в 1С:Бухгалтерия 8 ред. 3 от А до Я"? стоит ли тратить время (там больше 100 часов)...?
Очень и очень дорого )
Я в итоге его не смотрел.
Добавление элементов на форму при помощи редактора для меня равноценно удару серпом по тестикулам. Понятно, что это учебный пример, и основная тема вообще не о том. Илья, придерживаетесь ли Вы в своей регулярной практике концепции программной доработки типовых форм? Если да, то было бы интересно посмотреть стрим на эту тему. Спасибо.
Да, поддерживаю эту тему.
А почему это плохо?
@@First2603 удобнее при обновлении типовых.
В расширении же делал. Чем там то плохо не программное добавление.
@@bsnchita может на новых релизах с этим получше, но на 14-15 платформе было нереальное количество проблем с добавленными интерактивно элементами. Не отображались без видимых причин. Или после добавления реквизита формы нельзя было редактировать его свойства, приходилось переоткрывать под другой версией платформы ради этого. С программным добавлением в принципе могут быть только две проблемы: а) в новом релизе убрали/переименовали типовую группу, в которую вы добавили свой элемент. б) элемент связан с типовым реквизитом, который убрали/переименовали. Обе ситуации относительно редкие. Но даже в этих случаях ошибки исправляются проще.
Колби Ковингтон ещё и в 1С шарит? Ну могет 😀
А я в подобных задачах в расширение формы не добавляю. Ибо это очень гемморно в том плане что добавляется куча всего в расширение ненужного и даже вредного.
Есть общий модуль ПодключаемыеКоманды
В нем например добавляю:
&После("ПриСозданииНаСервере")
Процедура ЗП_ПриСозданииНаСервере(Форма, ПараметрыРазмещения = Неопределено) Экспорт
Если Форма.ИмяФормы = "Документ.РеализацияТоваровУслуг.Форма.ФормаСписка" Тогда
Форма.Список.ТекстЗапроса = СтрЗаменить(Форма.Список.ТекстЗапроса,"ДокументРеализацияТоваровУслуг.ВидОперации КАК ВидОперации,","ДокументРеализацияТоваровУслуг.ВидОперации КАК ВидОперации,"+Символы.ПС+"ДокументРеализацияТоваровУслуг.ЗП_ЗаказПокупателя КАК ЗП_ЗаказПокупателя,");
ЭлементФормы = Форма.Элементы.Вставить("ЗП_ЗаказПокупателя",Тип("ПолеФормы"),Форма.Элементы.Список, Форма.Элементы.Контрагент);
ЭлементФормы.ПутьКДанным = "Список.ЗП_ЗаказПокупателя";
ЭлементФормы.Вид = ВидПоляФормы.ПолеНадписи;
КонецЕсли;
КонецПроцедуры;
А такой код писать не геморно, по-твоему?)
@@IlyaLeontyev На самом деле не особо, так как код копипастом делается (из ранее так же дописанного), а не пишется заново. Зато всякие обновления, что сильно меняют форму этот код никак не затрагивают. Чуть сложнее, когда надо кнопочку разместить или на событие что-то помесить, но и тут обычно выход есть.
Ну и к тому же в расширение сразу видно что делал, а не добавлено куча объектов, для решения не нужных.
В типовых конфигурациях расширение достаточно добавить два общих модуля "МодификацияКонфигурации..."
Никаких объектов вместе с общим модулем в расширение добавлено не будет. Сама форма в расширении тоже не нужна.
РАЗРЕШЕНИЕ ЭКРАНА УДОБНОЕ! В СМАРТФОНЕ МОЖНО СМОТРЕТЬ! ВСЕ ВИДНО!!!
Илья, скажите пожалуйста за какую часовую оплату выт бы сделали эту задачу?
За мобилу респект
Скажите, вложенный запрос в «где»- это порядочно вообще?
Я как-то потестировал сложное условие, когда таблицы сравниваются в запросе по типу (Поле1, Поле2, Поле3) в () (в виртуальных таблицах БУ смотрел) и оказалось что работает всё это гораздо дольше чем просто условие по Поле1 в (), а остальные через соединение таблиц (полное). В моем случае я получал 62 счет обороты с условием (Субконто1, Субконто2) в (таб.Контрагент, таб.Договоры).
И в данном случае, может я чего-то пропустил, но зачем в финальной обработке результатов столько вложенных Выборка.Выбрать(), если по сути алгоритм линейный.
Ну и опять же я лично обычно обхожу именно ТЧ документа (просто потому что так понятнее) и заполняю её данными Таблицы в которую выгрузил результаты запроса и проиндексировав поля поиска.
Меня слегка переклинило на фоне подготовки к спецу по платформе ) Там постоянно используется проверка именно "В" ) Но там немного другая ситуация, поэтому соединение было бы более уместным здесь.
Хотя, учитывая скорость выполнения финального алгоритма, можно, наверно, и не оптимизировать уже ничего. Все работает достаточно быстро и правильно ) Остальное - уже придирки.
Вложенные циклы нужны для того, чтобы было удобно суммарный штрихкод вычислять. Итоги ведь в запросе. Не пойму, как по-другому сделать. Подскажешь?
Вариант с обходом ТЧ документа на клиенте в файловой базе не дает никаких преимуществ в производительности по сравнению с вариантом №2 (с запросами в цикле, на минуточку). Заполнение на стороне сервера значительно быстрее. (Ради чего, спрашивается, запрос оптимизировали?)
@@IlyaLeontyev Для конкретной задачи и так сойдет. Просто запросы подобные не только в заполнялках используются, но при построении отчетов, а там объем данных может быть очень большой и соответственно приходится их оптимизировать. Условие (п1,п2,п3) В (у1,у2,у3) иногда получается выполняется значительно дольше чем п1 в (у1), где это условие в виде параметров виртуальной таблицы а далее просто соединение полное по всем полям.
Обход всё равно делается на сервере, просто в твоем случае ты его в выборку запроса поместил, а я предпочитаю сначала сделать что-то типа ТЗ кэша ШК, а потом в нем уже искать перебирая строки чуть ниже. Просто код чуть логичнее получается, особенно когда запросы большие и кэшей таких несколько. Хотя в вашем конкретном случае быстрее думаю ваш вариант (на пару процентов), так как строки в документе одинаковые почти все. И ещё при оптимизации заметил, что поиск по ТЗ значительно быстрее работает если к ней добавлен индекс.
Так же, раз речь зашла о производительности, более сложные запросы обычно на SQL версии работают быстрее, чем на файловой, но вот вызовы идут дольше, а потому разница между 1 и 3 и даже 2 и 3 вариантом на SQL и больших данных будет более ощутима. И всё таки лучше взять в привычку писать сложные конструкции сразу, чем простые с формулировкой и так сойдет, так сказать набивать руку.
Говорят нынче спец по платформе сложно сдать, ибо платформа усложнилась. Сам-то в 2007 году получил.
Немного покоробило от "чисто программистского" подхода: "Я не уточнял зачем задача именно в такой постановке, хозяин - барин, говорит/платит - делаю". Консультант внутри меня негодует xDD Уже очень давно не подхожу к реализации "Тупо в лоб", всегда начинаю обсуждение задачи с вопроса "А зачем вам это нужно?". Считаю этот вариант безусловно верным, так как зачастую задача от изначальной постановки преобразуется просто до неузнаваемости. И именно на за это многие клиенты тебя и начинают ценить, так как кругозор клиента в плане возможных реализаций задачи очень узок, и кому как не нам помогать им в это тернистом пути? ))) Так тупо в лоб может работать только программист из команды, где до него с такими вопросами к клиенту уже отработали, и раз дошло до реализации, значит все аргументы не сработали, и действительно нужно делать именно так, не задавая других вопросов :)
А в остальном - норм, молодой поросли полезно смотреть на развитие мысли и прогресс реализации задач.
Про золотую середину между оптимальностью решения в плане производительности и удобства дальнейшего сопровождения - однозначно плюс, согласен.
Всегда контекст надо учитывать.
В данном случае у клиента уже была печатная форма с штрихкодами. И ему дополнительно к этой печатной форме понадобилось сделать такую хитрую штуку. В данном случае добивать клиента вопросами "А зачем вам это?" бессмысленно - мне все равно было нечего предложить взамен )
Возможно, его интересовала возможность постоянно менять состав колонок в "печатной форме". И сделать это дешево.
@@IlyaLeontyev Но нужно об этом долбить и долбить новичкам, каждый раз упоминать, проговаривать, иначе не по тому пути могут пойти ) В самом видео упустил, видимо, тот момент где задавался контекст. Если у клиента уже была печатная форма со штрихкодами, то да, изначальный помысел тем более интересен =))
Но все таки меня клиенты ценят как раз за то, что я их задолблю уточняющими вопросами, и добьюсь прояснения в их сознании =)) И мне спокойней - не делать в лоб, будучи просто инструментом, а помогать клиенту развиваться.
@@xalker да видео не об этом просто )
@@IlyaLeontyev Ну ок ))
Если не секрет, сколько выставил клиенту за эту задачу?
За нее разумно выставлять от одного до двух часов. Оценка зависит от того, каким способом в итоге задача была решена, и как много времени ушло на взаимодействие с клиентом. В некоторых тяжелых случаях (когда клиент не может нормально объяснить, что он хочет) можно и три выставлять.
Сколько выставил конкретно я, пожалуй, оставлю в тайне :)
Направление правильное. За решение реальных задач плюсую.
Но стиль Чистова как по мне устаревший. Ни кому не нужное общение со зрителями (малой частью подписчиков которым было удобно прийти на трансляцию) при чем не всегда по теме. Всегда есть шанс что тебя собьют, что то забудешь или что то пойдет не по плану (как например не правильно показанная сцена). Лучше записать видео и выложить его. Ни чего не будет забыто из того что запланировано. И можно расставить временные метки. Сейчас на ютубе это в роликах много кто стал практиковать (разбить например так: введение и постановка задачи, вариант 1, вариант 2, вариант 3, заключение). Если есть желание пообщаться , то запланировать показ отснятого ролика и потом сделать стрим с обсуждением. Это для случая как этот когда задача уже решена по сути.
Раз в две недели это для развития канала мало. Таких маленьких задач уверен много и их решение можно на стриме как раз и решать (онлайн так сказать). Оптимальный формат "каждый день новое видео" если это показ работы разумеется, а не поговорить.
Задача конечно дичь. Вместо печатной формы городить не нужную колонку . Хотя мне вообще заказывали вывод миниатюры картинки товара в тч документов.
а как такое сделать?
@@mrspacer1 Да на фига такое делать то? Я делал для УТ 11 так. У номенклатуры есть основное изображение. На его основе формируются миниатюры под высоту строки табличной части. Все это делается на лету. Если миниатюры еще нет, то она автоматом создается. Т.е. у номенклатуры получается в итоге несколько изображений. Ну а в списке номенклатуры и тч документов колонка с картинкой создается программно.
Я с мобилы
сравнение всех 3 способов сделано не правильно. Не ясно что будет если у клиента будет 20 (30,40,150...) юзеров которые одновременно жмут эти кнопки.
На стриме показали как делать НЕ НАДО! 1-2 способ, так могут написать ребята, которые только начали свою работу с 1с. А 3 вариант, что в итоге?
Было получено условие с подзапросом и 3 вложенных цикла, а допустим нам нужно получить данные по 7 измерениям и что будет 7 вложенных циклов? Через левое соединение запрос отработает в 2 раза быстрее. Я не заметил запретил ли ты редактирование колонки со штрихкодами или очищаешь эти поля, ведь пользователь обновляет поля для которых заведен в базе штрихкод, 99% процентов, что заказчик снова обратиться :)
Зачем при написании запроса в расширении тащить все объекты, ведь можно Запрос вызвать через Шаблоны текста? Дам совет не храните данные в расширении, и держите там как можно меньше объектов, лучше убедить заказчика включить возможность вносить изменения в конфигурацию. А вообще эту задачу уже решили, есть же отчет.
Почему ты не можешь вызвать конструктор СКД и не добавить макет туда?
Вот пример решение через СКД, кстати так эту задачу тоже решать не надо, но для примера того, что я написал можно показать. В товары нужно добавить колонку "Штрихкоды"
yadi.sk/d/hVvY4wBGWV_bvg
Если вы считаете что третий вариант такой уж и плохой, то что предлагаете?) а то это так выходит все тут неправильно сделал автор. Критикуеш - предлогай)
Вы писали за левое соединение, а зачем делать именно левое соединение если у нас допустим 100 товаров а штрихкод есть у одного товара) может уже тогда лучше сделать внутреннее соединение и связь тройную, но от куда вы увереннее что оно прям в два раза будет быстрее) я думаю оно будет так же а запрос будет еще длиннее.
И о каких шаблонах текста идет речь? Если о конструкторе во внешней обработке, то смотрите второй стрим - там это разжевывалось.
@@maxim.saharov , Я конечно прочитал ваш комментарий, хотя видео было выложено почти пол года назад. Абсолютно верно, левое соединение отработает быстрее, я провел замеры скорости выполнения. Так же я написал обработку и приложил ее к комментарию, которая соответствует первоначальному условию задачи я думаю моё предложение достаточное, а не просто слова в воздух. По второму вашему вопросу, автор ролика насколько я помню решал через расширение. В расширение при вызове Конструктора запроса нет доступа к объектам, которые не были добавлены в расширении и автор делал странный финт добавляя множество объектов в расширении, хотя не имея на это надобности. Большинство людей уже заметило, что при разработке через расширение удобно использовать СЕРВИС - ШАБЛОНЫ ТЕКСТА - СТАНДАРТНЫЕ - ПРОЧЕЕ - ЗАПРОС . При перемещении запроса в редактор у вас открывается доступ ко всем объектам, очень удобно. Максим можете скинуть ссылку на второй стрим где вся эта бездарность разжевывается? В комментарии я указал, что у меня не идеальное решение, кто знает тот поймет.
Просто надоело. Просматриваю "уроки" от разных авторов (без указания цели, для чего мне это нужно, после 20 лет работы с 1С). Но чем грешат ВСЕ авторы . И не глупые (вроде) люди, но ЗАЧЕМ убивать свое и чужое время на рассказ о том как делать неправильно? Поверьте, неправильно сделать (и гораздо более "неправильнее") все, вас смотрящие, могут и сами. Поэтому просьба: Не занимайтесь херней. Ставлю жирный дизлайк.
А зачем вы смотрите если такой подход не интересен) и тем более у вас 20 лет опыта и вы и так все знаете