Комментарии 24
Кстати, если мысленно представить, что мы начнем сейчас методично реализовывать пожелания, полученные 5-10 лет назад, то это будет очень забавно.
Некоторые фичи, например, всякие полезные вкусности для IDE (Конфигуратора) висят уже кучу лет и не устаревают.
Фактически многие вещи, внедренные или внедряемые сейчас в Конфигуратор, запрошены еще лет 10-12 назад :)
Когда скроете "отказ от модальности" с глаз обычных разработчиков конфигурации?
А как вы себе это представляете? Ну то есть, что именно (и как именно) должно быть скрыто?
Платформа "в браузере" (или ради чего у нас вышел отказ от модальности) заработала сама, без изменения "синхронного" кода на на встроенном языке. У "визуальных синхронных" (например Вопрос()) методов появился доп. параметр: "блокировать окно владельца", у "невизуальных" ничего дополнительного не появилось.
Сейчас это какая-то "синтаксическая горечь" получается, профита ноль, а простейший код типа обхода коллекции (по пути взаимодействуя с пользователем) с постобработкой, или там, рекурсивного обхода каталогов (на клиенте) превращается в спагетти.
Мелочи типа своей кнопки вместо стандартной, чтобы задать вопрос в "записать и закрыть" уже всем приелись.
Дополнительно появилась куча экспортных методов форм.
Появилась невозможность писать одинаковые алгоритмы с использованием невизуальных, но синхронных методов для клиента и для сервера.
Куча всякого, в общем. И если с приходом управляемых форм (который принес много вопросов, некоторые из которых не закрыты до сих пор) мы получили много новых возможностей, то с "отказом от модальности" новых возможностей нет, или они элементарно добавляются без глобальногооспагечиванияпереписывания алгоритмов.
Сейчас это какая-то "синтаксическая горечь" получается, профита ноль, а простейший код типа обхода коллекции (по пути взаимодействуя с пользователем) с постобработкой, или там, рекурсивного обхода каталогов (на клиенте) превращается в спагетти.
Мелочи типа своей кнопки вместо стандартной, чтобы задать вопрос в "записать и закрыть" уже всем приелись.
Дополнительно появилась куча экспортных методов форм.
Появилась невозможность писать одинаковые алгоритмы с использованием невизуальных, но синхронных методов для клиента и для сервера.
Куча всякого, в общем. И если с приходом управляемых форм (который принес много вопросов, некоторые из которых не закрыты до сих пор) мы получили много новых возможностей, то с "отказом от модальности" новых возможностей нет, или они элементарно добавляются без глобального
"синтаксическая горечь" — отличный термин для данной ситуации, записал в словарик. :)
А визуальность методов тут не при чем. Просто теперь все блокирующие поток выполнения API должны стать асинхронными. Тут речь не только про UI в-общем то. А вот то, что не появилось своего рода async/await это, конечно, несколько грустно. Синтаксическая горечь, ага.
ну если представить себе pure C с процедурным подходом, то там примерно то же получится. Слабое утешение, конечно, но хоть какое-то)
Пример с обходом коллекции и интерактивным взаимодействием он в принципе не может быть таким же, как в синхронном режиме, ибо у вас два разных потока будут работать до и после интерактива. Иными словами, совсем без доработок перейти в асинхрон не получится и странно требовать этого от 1С. Но "облегчить жизнь" добавлением какого-нибудь сахара, 1С, наверное могла бы. И я уверен, это наверняка обсуждалось, но потом были применены методики оценки приоритетов, указанные в статье, и данная задача была отброшена.
А визуальность методов тут не при чем. Просто теперь все блокирующие поток выполнения API должны стать асинхронными. Тут речь не только про UI в-общем то. А вот то, что не появилось своего рода async/await это, конечно, несколько грустно. Синтаксическая горечь, ага.
ну если представить себе pure C с процедурным подходом, то там примерно то же получится. Слабое утешение, конечно, но хоть какое-то)
Пример с обходом коллекции и интерактивным взаимодействием он в принципе не может быть таким же, как в синхронном режиме, ибо у вас два разных потока будут работать до и после интерактива. Иными словами, совсем без доработок перейти в асинхрон не получится и странно требовать этого от 1С. Но "облегчить жизнь" добавлением какого-нибудь сахара, 1С, наверное могла бы. И я уверен, это наверняка обсуждалось, но потом были применены методики оценки приоритетов, указанные в статье, и данная задача была отброшена.
Когда вы уже реализуете нормальную вертикальную прокрутку записей? А то даже в 8.3 всего три положения движка — сверху, посередине, снизу.
Вас усже услышали, правда своеобразно
А вообще это так работает потому что у списка в 1с принципиально не известно общее количество данных и позиция в этом общем количестве
Там динамическая подгрузка, поэтому ползунок так и работает. Есть еще интерфейсное решение, как в браузерах, когда вы скроллите до конца, а потом ползунок отпрыгивает обратно вверх. Но и в том и в другом случае ползунок вам врет. Вопрос в том, какой именно способ обмана вам нравится больше.
А есть ещё решения, когда всё же можно получить количество, а вот данные подгружать. Основная проблема с производительностью списков, что там тянут много полей разных объектов (ну не хотят бухи ничего понимать, хотят что бы прямо в списке номенклатуры им и остатки и цены и т.п. показывались и никаких отчётов — это же сложно, отчёт открывать) и часть полей делают вычислимыми, но получить количество элементов (а там всё работает на момент открытия и перечитыается только по специальной кнопочке, так что динамика это только на отображение) — никак не скажется на производительности, вот давайте теперь будем мучиться и жрать кактус, вернее жрём уже столько лет.
Ваша задача — понять цель заказчика. Цифры ему в списке нужны не просто так, а зачем-то. Выясните это зачем, какова цель, и выработайте способ, которым эта цель будет достигнута без серьезного ущерба производительности. Предложите варианты.
Если вы не смогли объяснить бухгалтеру, что список будет тормозить и вызывать только раздражение и не сделали ему удобное открытие отчета, то это ваша недоработка.
Если вы не смогли объяснить бухгалтеру, что список будет тормозить и вызывать только раздражение и не сделали ему удобное открытие отчета, то это ваша недоработка.
Нет, это ваша недоработка, потому что ползунок не работает на стандартных конфигурациях, что мешает предусмотреть механизм получения в динамический список общего количества и нормально прокручивать?
А с бухгалтерами мы как-то сами разбираемся, да и не моя эта задача, я в других сферах сейчас работаю, так что так что делайте внушение кому-нибдуь другому, раз уж в вас проснулся инстикт наставника.
А с бухгалтерами мы как-то сами разбираемся, да и не моя эта задача, я в других сферах сейчас работаю, так что так что делайте внушение кому-нибдуь другому, раз уж в вас проснулся инстикт наставника.
А вот ползунок отпрыгивающий назад, это не тот, который врёт, а это хороший приём, когда очень много данных и скорее всего пользователь их все не захочет смотреть, потому что выдача их ранжирована, например выдача гугла на какой-то запрос, в итоге навигацию вам оставляют только по тому, что вы уже посмотрели, а иметь каждый раз ползунок, где каждый миллиметр это сотни тысяч элементов, это как-то мало интересно. Ну и видимо остальные тоже стараются как могут, но не всегда понимают, что для 100 элементов такое решение — не нужно.
Спасибо за материал! А как вы оркеструете релизы? Есть ли некоторый выделенный человек, владеющий product roadmap? А также, есть ли некий выделенный человек, вроде главного архитектора, который определит, совместим ли набор предложенных фич друг с другом.
И у нас есть достаточно таких примеров, когда мы не брали готовое пожелание или решение, имеющееся в других технологиях, а придумывали и воплощали свою идею. И это давало очень большой эффект.
Насчёт эффекта. я весь в сомении, но велосипеды у вас сплошь и рядом, взять хотя бы Бухгалтерию и эта замечательная идея о ускорении, при разделении регистра на налоговый и бухгалтерский учёт, а этот замечательный РАУЗ, а СКД где по типу кубов, сначала тащится все данные и уже потом режутся, это же тихий ужас по объёмам? Да про то, что вы не релизы ни идеи не проверяете никогда, и выпускаете всё сырым, уже давно легенды слагают, возьмите последний релиз платформы 8.3.7, когда половина справочников открывалась пустыми и надо был крутить вверх что бы что-то увидеть, а в списках адресов вообще ничего нельзя было сделать, ваша идея, что форма не должна теперь скролиться, тоже очень оригинальна и что делать с непоместившимися элементами — не понятно, да и не видно, что что-то не влезло. И так можно ткнуть в любой релиз, и везде у вас косяки, если накатили обновление и не затёрлись данные кривой обработкой (да, бывает и такое — без возможности восстановления, 1с потом напишет мы же отозвали, остальное ваши проблемы). значит релиз — удачен. Про ориентированность на пользователей вы тоже классно поёте, на практике, помню зависала у вас регламентированная отчётность, после разбирательства выяснилось, что join платформа как-то криво обрабатывает и строится такой план, который отрабатывает больше 40 минут, я заменил на временную таблицу, стало пару секунд, а служба поддержки сказала — мы принципиально менять не будем ничего, у нас не энтерпрайз решение, поэтому НИКАКИХ оптимизаций запросов, идите нах.
"Исправлена в выпущенной версии" в Вашем багтрекере = "забили" ?
С таким подходом вы добавляете негатива от потребителя, который начинает смотреть на головную контору 1С, как на зажравшегося монстра.
В какой мере мы учитываем количество обращений по конкретному пожеланию? — В общем, учитываем. Но это не главный критерий.— остальное можно было не писать. «Пожелания» это не дурь потребителя, клиента, ЗАКАЗЧИКА и ПОКУПАТЕЛЯ.
С таким подходом вы добавляете негатива от потребителя, который начинает смотреть на головную контору 1С, как на зажравшегося монстра.
То есть по вашему, ткнуть в последнюю версию и попасть в недоработку которую видно невооружённым глазом, это — нормально!? и то что вы печёте заплатки на такую дребедень оправдывает постоянный выпуск сырого продукта?
Да вы и есть зажравшийся монстр, уже по минусам видно, как неистово вы минусите.
А на практие, не слишком шустрая работа платформы и конфигураций это очевидный факт, и только заржавшаяся контора может при этом вместо того, что бы оптимизировать конфигурации пытаться нажиться на этом, делая заведомо тормозной продукт, приговаривая "больше чем на 20 человек не рассчитано это не энетрепрайз", при этом какая-нибудь ЕРП будет не шибко быстрей, но зато есть возможности для оптимизации, когда-нибудь..
Да вы и есть зажравшийся монстр, уже по минусам видно, как неистово вы минусите.
А на практие, не слишком шустрая работа платформы и конфигураций это очевидный факт, и только заржавшаяся контора может при этом вместо того, что бы оптимизировать конфигурации пытаться нажиться на этом, делая заведомо тормозной продукт, приговаривая "больше чем на 20 человек не рассчитано это не энетрепрайз", при этом какая-нибудь ЕРП будет не шибко быстрей, но зато есть возможности для оптимизации, когда-нибудь..
Да вы на свои конфигурации посмотрите, при выгрузке из бухгалтерии плана счетов в зуп, половина перечислений дублировалась, потому что одни и те же наборы перечислений в каждой конфигурации прописаны по своему, даже такие элементарные вещи вы не устраняете годами, пользователям-то пофиг, ручками один раз поправят и живут, а об архитектуре и культуре разработки это говорит многое, можете минусить.
Про оптимизации я ещё раз повторю, 1с как виндовс работает всё быстрей и быстрей, но только на всё более быстром железе. А принципиальный подход не делать никаких оптимизаций озвученный официально, это достойно, весьма гибкий подход к клиенту. Да напишите в ответ что я что-то должен, как в прошлый раз, я посмеюсь.
muz-muz.net/storage/%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%BE%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%83%201%D1%81
Про оптимизации я ещё раз повторю, 1с как виндовс работает всё быстрей и быстрей, но только на всё более быстром железе. А принципиальный подход не делать никаких оптимизаций озвученный официально, это достойно, весьма гибкий подход к клиенту. Да напишите в ответ что я что-то должен, как в прошлый раз, я посмеюсь.
muz-muz.net/storage/%D0%BF%D0%B8%D1%81%D1%8C%D0%BC%D0%BE%20%D0%B4%D0%B8%D1%80%D0%B5%D0%BA%D1%82%D0%BE%D1%80%D1%83%201%D1%81
Хочу поделится своими наработками. Недавно сделал
Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux
Здесь побольше 1С кода.
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux 2
Например практически все программисты 1С используют ComОбъект.
По моей методе можно использовать
NetОбъект,NetТип
JavaОбъект,JavaТип
И эти объявления будут реально кроссплатформенны.
При это различия с ComОбъект минимальны. Имя класса равноценно комовскому ProgID. При этом нет ограничений на используемые типы.
Ты можешь написать свою библиотеку поместить в определенное место и использовать её вместо COM. Без регистрации итд. Расширять возможности 1С станет легче.
Например сейчас в конфигураторе куча функций, которые есть в стандартных библиотеках. При этом функционал 1С функций сильно недотягивает до стандартных библиотек.
Учитывая кроссплатформенность можно использовать нетовские или явовские библиотеки везде где можно. Упрощая программирование.
А что касается работы с HTTP,SMPT, JSON то эти библиотеки были задолго до того как 1С их реализовывала, при этом с ошибками и функционалом сильно недотягивающих до .Net или Java.
Стоит ли тратить время на то, что можно взять из стандартных библиотек. А ведь можно легко расширить за счет своих сборок.
При этом например нетовская библиотека весит всего 65 мегабайт, которую можно включить в дистрибутив и главное это кроссплатформенное решение. Причем нет сложного передавать в параметрах и объекты 1С которые поддерживают аналогичный интерфейс. Можно пойти по пути подсчета ссылок в 1С, а доступ к объектам 1С только на время вызова метода ВК.
Например Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент многие бы использовали на равне с ComОбъект, но главная причина её неприменения в том, что она неинтегрирована в 1С.
Даже если вы не хотите интегрировать .Net в 1С, то сделать вариант ВК под .Net и Java думаю стоит. Прежде всего для получения объектов ВК и передачи их в параметрах. Кроме того можно добавить доступ по индексу [], получения итератора.
Прошу прощения за сумбурность. Вроде как вещь полезная (реальная альтернатива IDispatch), но…
Кроссплатформенное использование классов .Net из неуправляемого кода. Или аналог IDispatch на Linux
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux
Здесь побольше 1С кода.
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux 2
Например практически все программисты 1С используют ComОбъект.
По моей методе можно использовать
NetОбъект,NetТип
JavaОбъект,JavaТип
И эти объявления будут реально кроссплатформенны.
При это различия с ComОбъект минимальны. Имя класса равноценно комовскому ProgID. При этом нет ограничений на используемые типы.
Ты можешь написать свою библиотеку поместить в определенное место и использовать её вместо COM. Без регистрации итд. Расширять возможности 1С станет легче.
Например сейчас в конфигураторе куча функций, которые есть в стандартных библиотеках. При этом функционал 1С функций сильно недотягивает до стандартных библиотек.
Учитывая кроссплатформенность можно использовать нетовские или явовские библиотеки везде где можно. Упрощая программирование.
А что касается работы с HTTP,SMPT, JSON то эти библиотеки были задолго до того как 1С их реализовывала, при этом с ошибками и функционалом сильно недотягивающих до .Net или Java.
Стоит ли тратить время на то, что можно взять из стандартных библиотек. А ведь можно легко расширить за счет своих сборок.
При этом например нетовская библиотека весит всего 65 мегабайт, которую можно включить в дистрибутив и главное это кроссплатформенное решение. Причем нет сложного передавать в параметрах и объекты 1С которые поддерживают аналогичный интерфейс. Можно пойти по пути подсчета ссылок в 1С, а доступ к объектам 1С только на время вызова метода ВК.
Например Использование сборок .NET в 1С 7.x b 8.x. Создание внешних Компонент многие бы использовали на равне с ComОбъект, но главная причина её неприменения в том, что она неинтегрирована в 1С.
Даже если вы не хотите интегрировать .Net в 1С, то сделать вариант ВК под .Net и Java думаю стоит. Прежде всего для получения объектов ВК и передачи их в параметрах. Кроме того можно добавить доступ по индексу [], получения итератора.
Прошу прощения за сумбурность. Вроде как вещь полезная (реальная альтернатива IDispatch), но…
Добавил статьи
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
Асинхронное программирование в 1С через .Net Native ВК
Теперь вызов .Net классов максимально приближен к коду на C#
Кроссплатформенное использование классов .Net в 1С через Native ВК. Или замена COM на Linux II
Асинхронное программирование в 1С через .Net Native ВК
Теперь вызов .Net классов максимально приближен к коду на C#
Добавил статью 1С,Linux,Excel,Word,OpenXML,Net Core
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как мы решаем «Что делать?»