Комментарии 101
Ну почему, почему, когда в СНГ берутся делать конструктор бизнес-приложений, то из пользовательского интерфейса вовсю «торчат уши» 1С? :(
Искренне и положа руку на сердце — запускал ваши онлайн-демо с ожиданием увидеть действительно современный UI ну хотя бы на уровне Dynamics 365. Но, увы — в реальности увидел всё ту же 1С парадигму, только реализованную на других технологиях :(
Пожалуйста, не надо так! У вас может получиться действительно классный и востребованный продукт, но для этого я бы очень советовал перенять современные подходы к проектированию CRUD интерфейсов.
Искренне и положа руку на сердце — запускал ваши онлайн-демо с ожиданием увидеть действительно современный UI ну хотя бы на уровне Dynamics 365. Но, увы — в реальности увидел всё ту же 1С парадигму, только реализованную на других технологиях :(
Пожалуйста, не надо так! У вас может получиться действительно классный и востребованный продукт, но для этого я бы очень советовал перенять современные подходы к проектированию CRUD интерфейсов.
А можете уточнить, что Вы подразумеваете под 1С парадигмой?
И в 1С, и в lsFusion и в Dynamics схема вроде одинаковая:
Разница лишь в дизайне, но не столь принципиальная, на мой взгляд.
Какие именно «современные подходы к проектированию CRUD интерфейсов» Вы имеете ввиду?
И в 1С, и в lsFusion и в Dynamics схема вроде одинаковая:
- Обычное иерархическое меню, где выбирается, например, Purchase orders
- Дальше идет список заказов с кнопками Добавить/Редактировать/Удалить
- Форма редактирования заказов, где можно задавать атрибуты шапки и табличная часть со список строк
Разница лишь в дизайне, но не столь принципиальная, на мой взгляд.
Какие именно «современные подходы к проектированию CRUD интерфейсов» Вы имеете ввиду?
Разница лишь в дизайне, но не столь принципиальная, на мой взгляд.
Смотря кого вы рассматриваете в качестве вашей целевой аудитории. Я работаю в компании, которая сама занимается разработкой ПО, и точно могу сказать, что ИТ специалистами вот такой дизайн интерфейса, как в 1С / InFusion, однозначно воспринимается как нечто архаичное, неудобное и отталкивающее.
В результате, мы сделали собственный конструктор на базе современных библиотек Web UI компонентов — пусть не такой универсальный, но гораздо более приятный и удобный визуально.
Какие именно «современные подходы к проектированию CRUD интерфейсов» Вы имеете ввиду?
В первую очередь, task-based UI:
Смотря кого вы рассматриваете в качестве вашей целевой аудитории
В качестве целевой аудитории мы рассматриваем бизнес. Интерфейсы делаем исключительно для сотрудников бизнеса. Бизнесу важно, чтобы сотрудники быстро и эффективно выполняли свою работу. Доплачивать за дизайн обычно никто не хочет. Поэтому основная задача состоит в том, чтобы быстро и дешево делать сотни объектов, таблиц и форм в соответствии с процессами заказчика, при помощи которых сотрудники будут их выполнять. На ваших скринах я вижу те же панели, таблички, просто красивее отрисованные. Однако, как я выше привел пример с Dynamics 365 Retail, это вовсе не значит, что с ними будет удобно работать.
пусть не такой универсальный, но гораздо более приятный и удобный визуально
Тут ключевая проблема именно в универсальности. Бизнес выберет решение, которое закрывает процессы на 100% без дизайна вообще, чем решением, которое покрывает 30% процессов, но очень красиво.
В первую очередь, task-based UI:
А какое отношение task-based UI имеет к CRUD? Можете дать ссылки на разъяснения того, что вы подразумеваете под этими терминами? А то видимо у нас разное представление о значении этих терминов. Если речь идет про BPM, то оно вообще обычно параллельно классическим CRUD интерфейсам.
Строго говоря в lsFusion можно custom design на React делать:
https://codesandbox.io/s/1y0o894rx4.
Тут и тут немного подробнее.
https://codesandbox.io/s/1y0o894rx4.
Тут и тут немного подробнее.
Попробуйте сделать подбор товара как в 1с 7.7 торговля и склад. Это самый быстрый удобный побор который я видел и пользовался. Многие мои знаковые в оптовой торговле не хотят до сих пор менять 1с 7.7 на 8. именно из-за удобства быстрого подбора товара в накладную.
К сожалению, не могу найти нигде в свободном доступе механизм подбора в 7.7. Чем он принципиально отличается от того, что описан в статье? Можете сделать GIF по аналогии с теми, что в статье, или скинуть ссылку на YouTube? Там тоже можно вводить количество в колонки?
Не понятно что вашим знакомым мешает в 8-ке сделать подбор как 7.7?
Начнем, я полагаю, с того факта, что в 8-ке нельзя редактировать значения прямо в списке (кроме табличных частей). Речь про УФ естественно, потому как если использовать ОФ, непонятно зачем вообще с 7.7 переходить.
Собственно даже текущий подбор через одно место сделан. Делается объект обработки с табличной частью и на форму выводится именно эта табличная часть.
Собственно даже текущий подбор через одно место сделан. Делается объект обработки с табличной частью и на форму выводится именно эта табличная часть.
Не совсем понятно о чем вы говорите, о списке или о таблице, но редактировать можно что там что там. Вы ничего не говорите о конфигурации, если речь о 10.3 то она не сильно от 9.2 отличается, если про УТ 11.4 то она конечно сильно отличается от 9.2, но подбор типовой работает везде сходным образом. Разница объясняется наличием возможности в 10.3 и 11.4 выписывать товар с нескольких складов в одной накладной, в 9.2 такой возможности нет.
Не совсем понятно о чем вы говорите, о списке или о таблице, но редактировать можно что там что там
А прокомментируйте тогда пожалуйста:
forum.mista.ru/topic.php?id=745039
forum.mista.ru/topic.php?id=791827
forum.infostart.ru/forum9/topic32107
forum-1c.ru/index.php?topic=34259.0
forum.mista.ru/topic.php?id=581751
Цитата из книги М.Г.Радченко «1С-Предприятие 8.2 — коротко о главном»:
Данные можно редактировать только в форме.
При работе в режиме управляемого приложения свойство объекта конфигурации Способ редактирования игнорируется, и данные редактируются всегда в отдельной форме.
Это относится ко всем таблицам, источником данных которых является динамический список.
Если же таблица имеет другой источник данных (табличная часть, дерево значений и т.д.), то ее данные редактируются непосредственно в списке.
Я собственно сейчас пробую в учебной версии это организовать, никак не получается. Может подскажете, как можно вытащить список товаров и сделать колонку которую можно редактировать, как в Axapta или lsFusion например.
PS: Ну и еще раз уточняю речь про УФ.
Начнем с того что в 7.7 не было динамических списков, вы тогда как в 9.2 делайте, выводите форму справочника, а остатки выводите в колонку «аля вычисляемое поле». Не уверен что в Axapta или lsFusion можно просто так отредактировать значение строки полученной в результате сложного запроса, у вас поле которое вы редактируете может быть результатом вычисления по полям из нескольких таблиц и не совсем понятно куда вы будите записывать значение?
Вы не полностью раскрываете задачу, но требуете решения. В 9.2 конфиге нет возможности ввести количество в подборе в ячейке, там выскакивает модальное окно с запросом количества или количества и цены в зависимости от настроек. Вы пишите о кастомном решение для конкретного клиента.
Вы не полностью раскрываете задачу, но требуете решения. В 9.2 конфиге нет возможности ввести количество в подборе в ячейке, там выскакивает модальное окно с запросом количества или количества и цены в зависимости от настроек. Вы пишите о кастомном решение для конкретного клиента.
Не уверен что в Axapta или lsFusion можно просто так отредактировать значение строки полученной в результате сложного запроса, у вас поле которое вы редактируете может быть результатом вычисления по полям из нескольких таблиц и не совсем понятно куда вы будите записывать значение?
Если это первичные данные (читай поле таблицы), то можно редактировать, и записываться будет в эти же данные (опять таки в поле таблицы), все из коробки. Более того можно для вычисляемого поля задать редактирование первичных данных (см. пример в статье) и форма сама автоматически обновится по окончании редактирования поля (сразу, а не после записи в базу !). Собственно посмотрите гифку подбора в lsFusion. Как такое же на 1С сделать?
В 9.2 конфиге нет возможности ввести количество в подборе в ячейке, там выскакивает модальное окно с запросом количества или количества и цены в зависимости от настроек. Вы пишите о кастомном решение для конкретного клиента.
Не совсем понял о каком кастомном решении речь идет. Обычный WYSIWYG, как в Excel, то есть видишь товары — заполняешь в колонку количество. Супер примитивный кейс.
Собственно об этом видимо и писал человек, когда говорил про 7.7.
Еще раз в Типовой 9.2 нет возможности как в Excel забить количество в ячейку.
Причем тут типовая? Речь о платформе. В УФ в принципе Excel-style интерфейсы строить нельзя. Только такое извращение как в статье, отдельно список товаров, отдельно строки с количеством, и добавление строк по двойному клику.
Собственно поэтому в 1С интерфейсы скажем так на любителя (речь не про дизайн, а именно про эргономику)
Собственно поэтому в 1С интерфейсы скажем так на любителя (речь не про дизайн, а именно про эргономику)
Если вы возьмете любой регламинтированый отчет в бухгалтерии, то там как раз
Excel-style интерфейс
Excel-style интерфейс
Ну речь шла все же про формы ввода (в частности подбор). Или что вы имеете ввиду под регламентированным отчетом, можете скрин скинуть?
Да речь о подборе, но как в 7.7. В 7.7 не как в Axapta или lsFusion. В 7.7 нет динамических списков, если хотите как в 7.7 то и делайте в 8-ке как в 7-ке делали, не через динамические списки.
Excel-style интерфейс это табличные документы, сделайте табличный документ, заполните его товарами и редактируйте на здоровье как в Excel
Excel-style интерфейс это табличные документы, сделайте табличный документ, заполните его товарами и редактируйте на здоровье как в Excel
Так а если товаров 100к, сервера не лягут при каждом открытии и изменении отбора заполнять таблицу значений на форме такими обьемами?
Это смотря какие у вас сервера, у меня если иерархию отключить в подборе, то как бы долго список выводится, но он у меня динамический и платформа оптимизирует вывод. Но так в лоб решать задачу все таки не стоит.
Что-то я совсем запутался.
Если список динамический — то там и проблемы нет, но и вводить ничего нельзя.
Если нет — то считывая 100к товаров в таблицу значений при каждом открытии / отборе у вас любой сервер ляжет.
Если список динамический — то там и проблемы нет, но и вводить ничего нельзя.
Если нет — то считывая 100к товаров в таблицу значений при каждом открытии / отборе у вас любой сервер ляжет.
Сервер не ляжет. Я говорю что идея считывать 100к не очень разумная идея.
То есть если 100 пользователей будут каждую минуту открывать и работать с формой подбора, а ширина записи товара скажем 1кб, то одно только это будет 10гб жрать, и это только одна таблица значений. Плюс затраты на ее заполнение.
В любом случае если вы говорите, что это не очень разумная идея. Как в 1С нормально (в смысле масштабируемо) реализовать ввод «как в Excel»?
В любом случае если вы говорите, что это не очень разумная идея. Как в 1С нормально (в смысле масштабируемо) реализовать ввод «как в Excel»?
Почему вы так зациклены на вводе как в Excel?
Я уже написал вам как, можете через табличный документ реализовать.
За мою 20 летнюю практику ни кто не настаивал именно на таком.
Я уже написал вам как, можете через табличный документ реализовать.
За мою 20 летнюю практику ни кто не настаивал именно на таком.
Почему вы так зациклены на вводе как в Excel?
Так как это WYSIWYG, то есть самый удобный и эргономичный способ. Ну реально не таким же извращением как в УТ 11 это делать.
Я уже написал вам как, можете через табличный документ реализовать.
Табличный документ это отчет. Вы предлагаете подбор через отчет делать? Серьезно? Плюс как там с отборами, сортировками и вообще куда там кнопку перенести в документ повесить?
За мою 20 летнюю практику ни кто не настаивал именно на таком.
Ну так может пользователи у вас ничего кроме 1С никогда не видели. А им там четко сказали не позволяют технические возможности и вообще дешево / у всех бухгалтерия на 1С и т.п.
не совсем понимаю при чем тут WYSIWYG
«Табличный документ это отчет.» табличный документ — это не отчет — это табличный документ, если вам так важен вид как в excel, то по кнопке подбор открывайте табличный документ, а не форму справочника
«Табличный документ это отчет.» табличный документ — это не отчет — это табличный документ, если вам так важен вид как в excel, то по кнопке подбор открывайте табличный документ, а не форму справочника
WYSIWYG — это означает, что я редактирую то что вижу, а вижу то что отредактировал. Без всплывающих окон, дополнительных списков и всякой такой ерунды.
Я правильно понимаю вы этот табличный документ имеете в виду:
Как в нем подбор можно сделать?
Я правильно понимаю вы этот табличный документ имеете в виду:
Как в нем подбор можно сделать?
Я имею в виду вот это http://v8.1c.ru/overview/Term_000000288.htm
Хотя табличные документы используются, в основном, для представления уже обработанной информации, существует возможность непосредственного ввода данных в табличный документ как в «обычную» электронную таблицу.
Хотя табличные документы используются, в основном, для представления уже обработанной информации, существует возможность непосредственного ввода данных в табличный документ как в «обычную» электронную таблицу.
Как я понял это все равно что в Paint редактировать, никакого отношения к данным не имеет.
Может конечно есть какой-то хак — привязать это к данным, но непонятно какое отношение это имеет к тому, что мы обсуждаем.
Может конечно есть какой-то хак — привязать это к данным, но непонятно какое отношение это имеет к тому, что мы обсуждаем.
Нет вы не поняли.
А можно тогда пример где табличный документ используется в качестве ввода данных в систему в виде списка? Я уже пару часов гуглю не могу найти ничего похожего.
Что вы имеете в виду под списком?
Вторая вкладка (Подбор). Там список товаров из ассортимента поставщика и туда же вводится значение.
Честно говоря я не понимаю в чем у вас проблема и почему вы не можете реализовать такой вариант. Табличный документ вам для этого точно подойдет. Откройте БП 3.0 возьмите Отчет по НДС, там подобное есть, не один в один, но понять можно.
Причем тут отчет? Мне отчёт на 100к товаров открывать каждый раз? Нужно как минимум чтобы только видимые данные читались, как в динамическом списке.
Ну и есть пример с кодом? А то все примеры что я видел там все руками надо делать.
Не понимаю в чем проблема повесить событие на выбор значения из поля поставщик и после этого заполнить табличный документ списком товаров поставщика? У поставщика же не будет 100К товаров
То есть вы все таки понимаете о чем речь :)
Во первых очень сильно зависит от поставщика, там и пару тысяч товаров может быть. А во вторых отбор по ассортименту поставщика может быть опциональным, то есть пользователь может его выключать и видеть скажем все остатки.
Ну и таблицу значений нужно руками по сути заполнять / записывать в базу, а не просто декларативно указать, что я хочу там видеть, как в lsFusion или динамическом списке, а дальше платформа все делает сама.
При заказе на продажу или списании товара нужно видеть товары всех поставщиков, которые есть в наличии (а при работе под заказ вообще всех).
Это у вас наверное сидит человек и глазками просматривает номенклатуру и делает заказ, а у меня в 1С делается формирование заказа обработкой и человек корректирует и там ну ни как 100к не получается. При списании зачем вам вся номенклатура, достаточно той что списываете, можно просто в табличной части набрать первые буквы списываемого товара и список покажется уже отфильтрованый
Ясно. Понятно. Классическая аргументация 1С программиста. «У меня вот так платформа умеет, а остальное вам не надо. И так сойдет.».
Причем здесь обработка? Как вернутся в интерфейс обработки, если пользователь ошибся и заказ уже сформирован и нужно видеть опять все данные?
Причем здесь обработка? Как вернутся в интерфейс обработки, если пользователь ошибся и заказ уже сформирован и нужно видеть опять все данные?
Мне кажется вы не читаете документацию раз задаете такие вопросы. Вы деньги заплатите тому кто знает как это сделать.
В <Параметры> передайте ссылку на документ, в обработчике открытия формы обработайте свою ситуацию.
Глобальный контекст (Global context)
ОткрытьФорму (OpenForm)
Вариант синтаксиса: По имени
Синтаксис:
ОткрытьФорму(<ИмяФормы>, <Параметры>, <Владелец>, <Уникальность>, <Окно>, <НавигационнаяСсылка>, <ОписаниеОповещенияОЗакрытии>, <РежимОткрытияОкна>)В <Параметры> передайте ссылку на документ, в обработчике открытия формы обработайте свою ситуацию.
Вы что под обработкой понимаете? Программный код по генерации автоматического заказа? И что там прямо и все праздники, прогноз погоды и взаимозаменяемость товаров учитываете, что пользователю прямо пару строк надо поменять, и даже не надо весь список товаров видеть?
Вы в УТ 11.4 видели блок планирования?
Блок планирования продаж? Угадывающий, что закажет клиент?
Планирования закупок.
А вы каким-то образом угадываете что закажет клиент?
А вы каким-то образом угадываете что закажет клиент?
Нет, поэтому и нужны подборы с вводом в списке товаров.
А исходя из чего у вас человек принимает решение о заказе того или иного товара и в каком количестве?
Исходя например из общения с человеком по телефону. Ну или например из собственных экспертных оценок. Понятно что система показывает ему реальные продажи, прогнозы продаж, предлагаемое системой количество к заказу и много чего еще, но решение часто принимает сам человек (хотя бывает когда процесс полностью автоматический, но это уже от пожеланий заказчика зависит).
в Axapta или lsFusion как то по другому данные на клиента попадаю?
Не совсем понял вопрос. В lsFusion данные тоже считываются видимыми порциями в результате SQL-запросов, но lsFusion умеет в этих запросах учитывать сделанные в сессии изменения и показывать данные с учетом изменений. А 1С нет.
Вы делаете не корректное утверждение что 1С так не умеет, 1С так умеет.
Ну так расскажите как, а то я уже второй день бодаюсь, не могу понять как реализовать такой подбор как в lsFusion в статье.
Вариант 1:
1) Добавляете на форму таблицу значений.
2) Пишете запрос для ее заполнения (или берете тот же, что используется в динамическом списке).
2*) Используете СКД для заполнения таблицы значений, чтобы не рисовать самому отборы и фильтры, а предоставить пользователю возможность настройки «как в динамическом списке».
3) Чтобы не грузить весь справочник целиком, по аналогии с динамическим списком, добавляете в запрос чтение данных порциями (реализуется с использованием конструкции «TOP N» ).
Вариант 2 (не подойдет для мобильного приложения):
1) Используете динамический список.
2) Передаете в него таблицу уже отобранных товаров.
3) Добавляете обработчик на выбор значения поля «Количество», который будет открывать окошко ввода количества (минус — отдельное окошко, плюс — на него можно навесить дополнительные функции типа добавления товара кратно упаковкам и т.д.)
Вариант 3 (По аналогии с регламентированной отчетностью 1С)
1) Заполняете список товаров в виде табличного документа (табличный документ можно размещать в том числе, как обычный элемент формы)
1*) Опять же — можно использовать СКД для его заполнения.
2) С помощью установки признаков разрешения или запрета редактирования конкретных полей или колонок, позволяете пользователю вносить информацию.
3) Программно считываете внесенные в табличный документ данные.
При необходимости настраиваем открытие карточек справочников/иных форм/выполнение действий при, например, двойном щелчке на конкретных ячейках табличного документа.
*Добавлено*
Вариант 2* (опять же — недоступен на мобильном):
Дозаполняем данные колонок динамического списка уже при полученнии его на форме, без передачи таблицы значений в запрос.
Вариант 2** (доступен на мобильном, но мягко говоря, костыль)
Помещаем данные не только в таблицу на форме, но и пишем их в БД.
1) Добавляете на форму таблицу значений.
2) Пишете запрос для ее заполнения (или берете тот же, что используется в динамическом списке).
2*) Используете СКД для заполнения таблицы значений, чтобы не рисовать самому отборы и фильтры, а предоставить пользователю возможность настройки «как в динамическом списке».
3) Чтобы не грузить весь справочник целиком, по аналогии с динамическим списком, добавляете в запрос чтение данных порциями (реализуется с использованием конструкции «TOP N» ).
Вариант 2 (не подойдет для мобильного приложения):
1) Используете динамический список.
2) Передаете в него таблицу уже отобранных товаров.
3) Добавляете обработчик на выбор значения поля «Количество», который будет открывать окошко ввода количества (минус — отдельное окошко, плюс — на него можно навесить дополнительные функции типа добавления товара кратно упаковкам и т.д.)
Вариант 3 (По аналогии с регламентированной отчетностью 1С)
1) Заполняете список товаров в виде табличного документа (табличный документ можно размещать в том числе, как обычный элемент формы)
1*) Опять же — можно использовать СКД для его заполнения.
2) С помощью установки признаков разрешения или запрета редактирования конкретных полей или колонок, позволяете пользователю вносить информацию.
3) Программно считываете внесенные в табличный документ данные.
При необходимости настраиваем открытие карточек справочников/иных форм/выполнение действий при, например, двойном щелчке на конкретных ячейках табличного документа.
*Добавлено*
Вариант 2* (опять же — недоступен на мобильном):
Дозаполняем данные колонок динамического списка уже при полученнии его на форме, без передачи таблицы значений в запрос.
Вариант 2** (доступен на мобильном, но мягко говоря, костыль)
Помещаем данные не только в таблицу на форме, но и пишем их в БД.
Спасибо за ответ. Собственно я так и думал, но тут мягко говоря есть ряд вопросов:
Вариант 1:
1) А что делать со скроллингом? То есть пользователь нажал pagedown, надо дочитать еще данные, что дальше делать? Еще один запрос? Но тогда туда придется достаточно сложные условия добавлять вроде Порядок1 = ТекущееЗначениеПорядка1 И Порядок2 > ТекущееЗначениеПорядка2 ИЛИ Порядок1 > ТекущееЗначениеПорядка1.
2) Непонятно что делать с измененными значениями. То есть пользователь что-то изменил в этой таблице, проскроллил вниз, проскроллил вверх он должен увидеть, то что он изменил. То есть нужно сливать ранее измененные значения со считанными. Как это поддержать?
3) Вы понимаете сколько там кода будет при этом? То что в lsFusion из коробки одной строчкой делается.
Вариант 2: Смысл то как раз в том чтобы не вызывать диалог. Но даже с диалогом не совсем понял, то есть предполагается, что надо руками хранить, что пользователь изменил, и при открытии диалога дополнительно проверять не измененные ли это данные. Плюс я так понимаю это надо как-то в запросе динамического списка учитывать (он вообще к таблицам значения обращаться умеет?), и вручную заставлять этот динамический список обновляться при изменении таблицы значений с изменениями. В любом случае вы опять-таки представляете сколько кода при этом будет? Реально интересно посмотреть пример кода, потому что в том же УТ все интерфейсы это убогие списки и диалоги. В лучшем случае как в подборе два списка в одном выбираешь, в другом вводишь.
Вариант 3:
А как его сделать динамическим, чтобы только порциями записи читались? Ну и вы же представляете какое это извращение ввод в отчете реализовывать, и там кода будет еще больше чем в первых двух вариантах.
Вариант 1:
1) А что делать со скроллингом? То есть пользователь нажал pagedown, надо дочитать еще данные, что дальше делать? Еще один запрос? Но тогда туда придется достаточно сложные условия добавлять вроде Порядок1 = ТекущееЗначениеПорядка1 И Порядок2 > ТекущееЗначениеПорядка2 ИЛИ Порядок1 > ТекущееЗначениеПорядка1.
2) Непонятно что делать с измененными значениями. То есть пользователь что-то изменил в этой таблице, проскроллил вниз, проскроллил вверх он должен увидеть, то что он изменил. То есть нужно сливать ранее измененные значения со считанными. Как это поддержать?
3) Вы понимаете сколько там кода будет при этом? То что в lsFusion из коробки одной строчкой делается.
Вариант 2: Смысл то как раз в том чтобы не вызывать диалог. Но даже с диалогом не совсем понял, то есть предполагается, что надо руками хранить, что пользователь изменил, и при открытии диалога дополнительно проверять не измененные ли это данные. Плюс я так понимаю это надо как-то в запросе динамического списка учитывать (он вообще к таблицам значения обращаться умеет?), и вручную заставлять этот динамический список обновляться при изменении таблицы значений с изменениями. В любом случае вы опять-таки представляете сколько кода при этом будет? Реально интересно посмотреть пример кода, потому что в том же УТ все интерфейсы это убогие списки и диалоги. В лучшем случае как в подборе два списка в одном выбираешь, в другом вводишь.
Вариант 3:
А как его сделать динамическим, чтобы только порциями записи читались? Ну и вы же представляете какое это извращение ввод в отчете реализовывать, и там кода будет еще больше чем в первых двух вариантах.
1)
Условие «первые <ЧислоЭлементовНаЭкране> ИЗ (Первые <ЧислоЭлементовНаЭкране + Смещение>)».
2)
Вы хотели редактирование «как в Excel» и утверждали, что на 1С это реализовать не возможно. Я предложил несколько различных вариантов реализации. Количество строк кода сравнивать смысла не вижу. Иначе я могу, например, напомнить, что какой-нить динамический список справочника в 1С можно создать без единой строчки кода и нажатий на кнопки мыши — система автоматически сгенерирует ее при обращении к справочнику.
Во-вторых, отборы/сортировки/условные оформления/поиск по подстроке доступные в динамических списках без единой строчки кода, в том числе на уровне пользователя, на lsfusion также можно реализовать с помощью 1-2 строк?
3)
4)
Да, придется хранить в таблице значений.
Да, фактически данные вносятся и редактируются именно в ней, после изменения — обновляются данные динамического списка (фактически — измененная таблица передается в качестве параметра списка, платформа обновить информацию автоматически).
По количеству кода уже писал выше. Нужно составлять полностью совпадающие по возможностям формы и только после этого начинать сравнивать количество строк кода, раз уж для вас это так важно.
5)
Точно также как и с таблицей значений.
6)
Понимаете, для меня тот вариант подбора, который реализован у вас, кажется извращением. Это вопрос вкусов и привычек.
Но если подходить формально — ввод данных в табличном документе, наиболее близко подходит к определению «как в Excel».
Но тогда туда придется достаточно сложные условия добавлять
Условие «первые <ЧислоЭлементовНаЭкране> ИЗ (Первые <ЧислоЭлементовНаЭкране + Смещение>)».
2)
Вы понимаете сколько там кода будет при этом? То что в lsFusion из коробки одной строчкой делается
Вы хотели редактирование «как в Excel» и утверждали, что на 1С это реализовать не возможно. Я предложил несколько различных вариантов реализации. Количество строк кода сравнивать смысла не вижу. Иначе я могу, например, напомнить, что какой-нить динамический список справочника в 1С можно создать без единой строчки кода и нажатий на кнопки мыши — система автоматически сгенерирует ее при обращении к справочнику.
Во-вторых, отборы/сортировки/условные оформления/поиск по подстроке доступные в динамических списках без единой строчки кода, в том числе на уровне пользователя, на lsfusion также можно реализовать с помощью 1-2 строк?
3)
Непонятно что делать с измененными значениями. Передавать таблицу значений, с зафиксированными количествами товаров в качестве параметра запроса (фактически, это может быть сама таблица на форме или ее сокращенный вариант с отбором по значению реквизита «Количество» и только необходимыми колонками ).
4)
Но даже с диалогом не совсем понял, то есть предполагается, что надо руками хранить, что пользователь изменил, и при открытии диалога дополнительно проверять не измененные ли это данные. Плюс я так понимаю это надо как-то в запросе динамического списка учитывать (он вообще к таблицам значения обращаться умеет?), и вручную заставлять этот динамический список обновляться при изменении таблицы значений с изменениями
Да, придется хранить в таблице значений.
Да, фактически данные вносятся и редактируются именно в ней, после изменения — обновляются данные динамического списка (фактически — измененная таблица передается в качестве параметра списка, платформа обновить информацию автоматически).
По количеству кода уже писал выше. Нужно составлять полностью совпадающие по возможностям формы и только после этого начинать сравнивать количество строк кода, раз уж для вас это так важно.
5)
А как его сделать динамическим, чтобы только порциями записи читались?
Точно также как и с таблицей значений.
6)
Ну и вы же представляете какое это извращение ввод в отчете реализовывать
Понимаете, для меня тот вариант подбора, который реализован у вас, кажется извращением. Это вопрос вкусов и привычек.
Но если подходить формально — ввод данных в табличном документе, наиболее близко подходит к определению «как в Excel».
Условие «первые <ЧислоЭлементовНаЭкране> ИЗ (Первые <ЧислоЭлементовНаЭкране + Смещение>)».
Не понял что это значит, можно расшифровать на каком-нибудь простом примере.
утверждали, что на 1С это реализовать не возможно
Ну 1С тьюринг-полный язык на нем можно и танки реализовать теоретически. Речь шла о том, чтобы реализовать хоть сколько нибудь декларативно.
Иначе я могу, например, напомнить, что какой-нить динамический список справочника в 1С можно создать без единой строчки кода и нажатий на кнопки мыши — система автоматически сгенерирует ее при обращении к справочнику.
Во-вторых, отборы/сортировки/условные оформления/поиск по подстроке доступные в динамических списках без единой строчки кода, в том числе на уровне пользователя, на lsfusion также можно реализовать с помощью 1-2 строк?
Давайте определим, что значит без единой строчки кода. Вы же понимаете что нет никакой разницы программировать мышкой или клавиатурой. Потому как иначе я могу взять любую обучалку детей программированию и там тоже «не будет ни одной строки кода».
А вообще lsFusion умеет делать не только, то что вы говорите, но и то что 1С близко не умеет: поддерживает редактирование и автоматическое реактивное обновление формы при любом таком редактировании (без каких либо дополнительных обработчиков).
Передавать таблицу значений, с зафиксированными количествами товаров в качестве параметра запроса
Я правильно понимаю, так как там придется LEFT JOIN с этой таблицей значений, то придется вот такое извращение делать:
// Сначала выбираем переданные значения во временную
// таблицу, а уже затем работаем с временной таблицей
// как с обычной.
Запрос = Новый Запрос(
"ВЫБРАТЬ
| Название,
| Численность
|ПОМЕСТИТЬ
| ВременнаяТаблица
|ИЗ
| &ТаблицаСтран КАК Страны
|;
|ВЫБРАТЬ
| Название,
| Численность
|ИЗ
| ВременнаяТаблица
|УПОРЯДОЧИТЬ ПО
| Численность УБЫВ"
);
Запрос.УстановитьПараметр("ТаблицаСтран", Страны);
По количеству кода уже писал выше. Нужно составлять полностью совпадающие по возможностям формы и только после этого начинать сравнивать количество строк кода, раз уж для вас это так важно.
Я снизу привел пример формы. И пытаюсь представить как такое на 1С сделать, там придется строк 100 причем весьма извращенного кода написать (прежде всего для поддержки скроллинга, хотя я до сих пор не понимаю как вы это предлагаете делать)
Точно также как и с таблицей значений.
Как также? В отчете есть событие изменение текущего ряда? Можно где-нибудь на demo-ma.1c.ru посмотреть как это работает?
Понимаете, для меня тот вариант подбора, который реализован у вас, кажется извращением. Это вопрос вкусов и привычек.
Но если подходить формально — ввод данных в табличном документе, наиболее близко подходит к определению «как в Excel»
Это обычный Excel. Вы же понимаете что большинство людей привыкло к Excel и WYSIWYG. Или вы реально считаете что подбор с двумя списками это нормально?
Но как вы правильно заметили, это вопрос вкусов и привычек. Но не ваших, а пользователя, и заставлять их работать так как умеет 1С это верх садизма (в смысле что в примере lsFusion пользователь может сам выбрать Excel или Doc style)
Не понял что это значит, можно расшифровать на каком-нибудь простом примере.
На MySQL «SELECT * FROM table LIMIT N OFFSET 0;»
У 1С нет OFFSET во встроенном языке запросов, но есть ПЕРВЫЕ (TOP), соответственно
SELECT TOP N FROM (SELECT TOP Offset+N DESC). N — число элементов на странице, Offset — смещение от начала списка.
Давайте определим, что значит без единой строчки кода. Вы же понимаете что нет никакой разницы программировать мышкой или клавиатурой.
Это значит «без единой строчки кода». Система автоматически генерирует формы карточки/списка для объектов метаданных, если разработчик не озаботился их созданием.
А вообще lsFusion умеет делать не только, то что вы говорите, но и то что 1С близко не умеет: поддерживает редактирование и автоматическое реактивное обновление формы при любом таком редактировании (без каких либо дополнительных обработчиков).
В демо примерах я вижу только возможность скрыть/показать заранее добавленные в коде колонки, поменять их заголовок и возможность простейшей фильтрации таблицы по «равно/не равно/like».
В каком демо примере можно посмотреть что-то похожее на «настройку формы» или «настройку списка» из 1С? Напоминаю, в 1С для этого не требуется написания кода/добавления обработчиков/даже мышкой ничего нажимать не нужно.
Как также? В отчете есть событие изменение текущего ряда?
Как вам уже пытались донести, «табличный документ» это не «отчет». Это компонента, если хотите, для отображения информации (да, в том числе отчетов)
Да, для табличного документа есть возможность обрабатывать события изменения данных в ячейке, активизации и выделения ячейки и т.д.
Посмотреть как это работает можно в типовой регламентированной отчетности для бухгалтерии, добавление валют из классификатора в УНФ. Любой отчет с расшифровкой, в конце концов.
Это обычный Excel.
Это не эксель. У вас нет формул, макросов, заполнения полей протаскиванием и т.д.
Вы же понимаете что большинство людей привыкло к Excel и WYSIWYG.
и заставлять их работать так как умеет 1С это верх садизма (в смысле что в примере lsFusion пользователь может сам выбрать Excel или Doc style)
Да, часть пользователей пытается все делать «как в excel», такие пользователи и у меня есть. Они же вместо нормальных отчетов просят сделать им простыни на 100 колонок и десятки тысяч строк, для того чтобы крутить их с помощью сводных таблиц и предпочитают заниматься вводом данных с помощью «Экспорт в Excel — Редактирование — Импорт в 1С».
При этом, у меня также есть пользователи, которые верхом садизма будут считать делать так, как предлагаете вы.
Увы, мир несовершенен.
Или вы реально считаете что подбор с двумя списками это нормально?
Откройте любой интернет магазин с корзиной товаров. Как ни странно — но это именно два списка с редактированием количества в отдельном окне.
На MySQL «SELECT * FROM table LIMIT N OFFSET 0;»
У 1С нет OFFSET во встроенном языке запросов, но есть ПЕРВЫЕ (TOP), соответственно
SELECT TOP N FROM (SELECT TOP Offset+N DESC). N — число элементов на странице, Offset — смещение от начала списка.
Во-первых OFFSET в принципе не правильно использовать потому как данные могут меняться и вы просто не попадете в ту запись на которой стояли. Во вторых при таком запросе половину СУБД (Postgres так точно), когда вы end нажмете, начнет всю таблицу сканировать.
В каком демо примере можно посмотреть что-то похожее на «настройку формы» или «настройку списка» из 1С? Напоминаю, в 1С для этого не требуется написания кода/добавления обработчиков/даже мышкой ничего нажимать не нужно.
Она телепатически догадается, что нужно добавить?
Расскажите что в «настройку формы» или «настройку списка» входит, а то я создал форму с запросом и не вижу что в нем можно что-то настраивать. Хотя если честно я даже в необходимости настройки таблицы не уверен, так как это не попадает под систему контроля версий и соответственно сильно усложняет поддержку в будущем.
В любом случае мы расширенную настройку тоже поддержим, это достаточно примитивная задача по сравнению с тем же редактированием. А вот у 1С родовая травма останется похоже навечно.
Да, для табличного документа есть возможность обрабатывать события изменения данных в ячейке, активизации и выделения ячейки и т.д.
Посмотреть как это работает можно в типовой регламентированной отчетности для бухгалтерии, добавление валют из классификатора в УНФ. Любой отчет с расшифровкой, в конце концов.
Так еще раз. Он умеет только 25 записей считать и дочитывать их по мере перемещения в ячейках. Мне именно этот кейс интересен. Можете на моем примитивно примере из 2 колонок продемонстрировать.
Увы, мир несовершенен.
Согласен поэтому платформа должна позволять и то и другое. А 1С позволяет по факту только одно.
Откройте любой интернет магазин с корзиной товаров. Как ни странно — но это именно два списка с редактированием количества в отдельном окне.
Это потому что вы в интернет магазине долго выбираете и хорошо если хотя бы 2 товара покупаете. Если вы сразу 100 позиций будете заказывать, это очень неудобно будет.
То есть вопрос, какое минимальное число строчек займет такой функционал (но так чтобы это работало когда товаров 100к):
Это в lsFusion создаст форму с товарами, которую можно редактировать как в Excel.
Тут можно посмотреть что получится: lsfusion.org/try Вкладка платформа, просто вставить, нажать play.
CLASS Sku;
name = DATA STRING (Sku);
quantity = DATA STRING (Sku);
FORM skuForm
OBJECTS s=Sku
PROPERTIES (s) name, quantity, NEW, DELETE
;
NAVIGATOR {
NEW skuForm;
}
Это в lsFusion создаст форму с товарами, которую можно редактировать как в Excel.
Тут можно посмотреть что получится: lsfusion.org/try Вкладка платформа, просто вставить, нажать play.
Получилась форма с табличкой. В которой колонки нетипизированы и никак не привязаны к данным. Это не особенно тянет на «форму с товарами, которую можно редактировать как в excel», простите.
Они типизированы и привязаны к данным.
То есть дальше делаем:
CLASS Document;
CLASS DocumentDetail;
document = DATA Document (DocumentDetail);
sku = DATA Sku (DocumentDetail);
nameSku(DocumentDetail dt) = name(sku(dt));
FORM
OBJECTS d=Document, dt=DocumentDetail
FILTERS document(dt) = d
PROPERTIES (dt) nameSku
;
И вводим документ, при нажатии на имя товара будет список из товаров, введенных в этой «excel» форме.
Или вы что-то другое имеете ввиду?
То есть дальше делаем:
CLASS Document;
CLASS DocumentDetail;
document = DATA Document (DocumentDetail);
sku = DATA Sku (DocumentDetail);
nameSku(DocumentDetail dt) = name(sku(dt));
FORM
OBJECTS d=Document, dt=DocumentDetail
FILTERS document(dt) = d
PROPERTIES (dt) nameSku
;
И вводим документ, при нажатии на имя товара будет список из товаров, введенных в этой «excel» форме.
Или вы что-то другое имеете ввиду?
Возможно неудачно выразился. Смущает, что количество — это строка.
Контроля остатков и показа их — нет. Цен тут тоже нет и т.д. и т.п., тем не менее уже добавились дополнительные 10 строк кода, а форма выглядит как «привет из 1С 7.x» 94 года выпуска (хотя да, там бы пришлось больше строк кода написать — тут победа).
Контроля остатков и показа их — нет. Цен тут тоже нет и т.д. и т.п., тем не менее уже добавились дополнительные 10 строк кода, а форма выглядит как «привет из 1С 7.x» 94 года выпуска (хотя да, там бы пришлось больше строк кода написать — тут победа).
Издеваетесь? Я специально взял максимально простой случай, чтобы была понятна разница. Замените количество, не знаю на номер.
Вообще более сложная задача тут:
documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
Production-ready тут:
github.com/lsfusion-solutions/erp
Но если начать усложнять пример, поверьте, это будет не в пользу 1С. Ну и 95% форм в том же УТ состоящих из простейших списков это все тот же 1С 7.7 94 года выпуска. Или вы реально думаете что раскрасив их поярче что-то изменилось.
Вообще более сложная задача тут:
documentation.lsfusion.org/pages/viewpage.action?pageId=2228636
Production-ready тут:
github.com/lsfusion-solutions/erp
Но если начать усложнять пример, поверьте, это будет не в пользу 1С. Ну и 95% форм в том же УТ состоящих из простейших списков это все тот же 1С 7.7 94 года выпуска. Или вы реально думаете что раскрасив их поярче что-то изменилось.
В любом случае меня интересует форма на 1С именно в постановке как я написал. Просто сейчас готовится статья «Почему не 1С» и там будет в том числе пункт про редактирование списков, возможно мы что-то упускаем, и есть какой-то простой способ реализовать эту форму.
Ну и если конечно не трудно, хотя бы приблизительный код этой формы на 1С, чтобы мы могли в статью добавить. Мы были бы очень благодарны.
Ну и если конечно не трудно, хотя бы приблизительный код этой формы на 1С, чтобы мы могли в статью добавить. Мы были бы очень благодарны.
Ну и если конечно не трудно, хотя бы приблизительный код этой формы на 1С, чтобы мы могли в статью добавить. Мы были бы очень благодарны.
Ну вы ведь готовите статью «почему не 1С», вот и готовьте. Изучите например платформу, а то у вас те же проблемы что и 10 лет назад (только тогда вы продавали пользователям LSTrade и убеждали на своем сайте, что создание собственной платформы и собственного языка — это глупость и 1С пошла по неверному пути) — вы не знаете возможностей платформы 1С, но уверенно рассказываете о своих преимуществах.
Я уже неделю изучаю. Сверху приводили 5 разных форумов, где все говорят что нельзя так делать.
Но вы один утверждаете, что можно. И я все хочу выяснить как, может это какое-то секретное знание.
Хотя это какая-то странная фишка 1Сцев. Нет, чтобы просто сказать, да не умеет. Но нет, они будут защищать платформу до последней капли крови.
В любом случае не хотите, можете не отвечать, я вполне уверен, что был бы простой способ вы бы его привели. Это все что мне нужно было узнать. Лично вас я не переубежу, я это уже понял.
Но вы один утверждаете, что можно. И я все хочу выяснить как, может это какое-то секретное знание.
Хотя это какая-то странная фишка 1Сцев. Нет, чтобы просто сказать, да не умеет. Но нет, они будут защищать платформу до последней капли крови.
В любом случае не хотите, можете не отвечать, я вполне уверен, что был бы простой способ вы бы его привели. Это все что мне нужно было узнать. Лично вас я не переубежу, я это уже понял.
CSS никто не отменял. Можно себе разрисовать как угодно. Просто никому не надо. Выше уже писали про это.
Дело в том, что в B2B гораздо важнее не дизайн, а скорость работы. Так вот в веб-версии и 1С, и Dynamics, лично мне хочется чем-нибудь кинуть в монитор после пары минут работы, так как там на базовых простых действиях (типа открытия формы) висит по пару секунд и постоянно что-то «залипает». А если форма сложная, то вообще просто ужас. У нас есть клиенты, которые работают и с 1С и с lsFusion, так вот им тоже сначала не понравился дизайн. Но потом, когда привыкли, признали, что гораздо важнее то, что в lsFusion все летает.
Дело в том, что в B2B гораздо важнее не дизайн, а скорость работы. Так вот в веб-версии и 1С, и Dynamics, лично мне хочется чем-нибудь кинуть в монитор после пары минут работы, так как там на базовых простых действиях (типа открытия формы) висит по пару секунд и постоянно что-то «залипает». А если форма сложная, то вообще просто ужас. У нас есть клиенты, которые работают и с 1С и с lsFusion, так вот им тоже сначала не понравился дизайн. Но потом, когда привыкли, признали, что гораздо важнее то, что в lsFusion все летает.
Было бы интересно вернуться к вопросу динамического вывода на форму списка номенклатуры при подборе в Заказ. И 1С, и lsFusion позволяют пользоваться обычным браузером как клиентом (веб-клиентом) для подключения к собственно серверу (т.н. серверу приложений, главному, наверное, из механизмов платформы). Рассмотрю этот способ для наглядности.
Понятно, что для вывода списка номенклатуры сервер должен запросить этот список весь или частично у СУБД и отдать на клиент. Хотелось бы знать: если список большой, и клиент получает список порциями по мере того, как пользователь движется по списку вниз, кэшируется ли на клиенте какое-то количество позиций? А на сервере?
В 1С, насколько мне известно, клиент имеет только ту часть списка, которую в данный момент отображает. А вот на сервере можно при желании хранить в кэше некоторое количество данных. Чтобы не запрашивать у БД еще раз первые порции, если, к примеру, пользователь захочет вернуться к началу списка. А как с этим дело у lsFusion?
Понятно, что для вывода списка номенклатуры сервер должен запросить этот список весь или частично у СУБД и отдать на клиент. Хотелось бы знать: если список большой, и клиент получает список порциями по мере того, как пользователь движется по списку вниз, кэшируется ли на клиенте какое-то количество позиций? А на сервере?
В 1С, насколько мне известно, клиент имеет только ту часть списка, которую в данный момент отображает. А вот на сервере можно при желании хранить в кэше некоторое количество данных. Чтобы не запрашивать у БД еще раз первые порции, если, к примеру, пользователь захочет вернуться к началу списка. А как с этим дело у lsFusion?
И на сервере и на клиенте читается / хранится только видимая часть (условных 50 записей). Особого смысла кэшировать эти данные ни на сервере приложений, ни на клиенте нет, так как а) данные могут меняться и тогда они будут не актуальными, б) СУБД сами имеют кэши вроде shared buffers у PostgreSQL, которые и используются в частности при page'инге, в) пользователь не так часто листает вверх, потом вниз, потом опять вверх, потом опять вниз, чтобы cache hit ratio был высоким и затраты на кэширование были бы меньше чем эффект от этого кэширования.
данные могут меняться и тогда они будут не актуальными
Для таких случаев должны быть тригеры, оповещающие кэши об устаревании при необходимости. Но соглашусь, что кэширование целесообразно не всегда, и в 1С, например, кэширование на сервере можно не использовать.
<СУБД сами имеют кэши>
Ну… можно, конечно, и отдать этот вопрос на откуп СУБД. Это уже тема выбора СУБД, которые поддерживает фреймворк. Другое дело, что вообще далеко не всегда есть желание/возможность у конечного пользователя разворачивать на локальной машине отдельную СУБД для использования локальной системы учета. Хорошо, что есть платформы, где это не обязательно.
пользователь не так часто листает вверх, потом вниз, потом опять вверх, потом опять вниз, чтобы cache hit ratio был высоким
А вот тут в корне не соглашусь. В случаях, когда в некоей таблице хранится действительно большое количество записей, наивно надеяться, что никто никогда не захочет плотно поработать с записями, листая таблицу и в хвост и в гриву.
Для таких случаев должны быть тригеры, оповещающие кэши об устаревании при необходимости. Но соглашусь, что кэширование целесообразно не всегда, и в 1С, например, кэширование на сервере можно не использовать.
Если триггеры будут просто уведомлять об изменении в таблице, то кэши будут сбрасываться постоянно. А если обновлять кэши, то оверхед от такого обновления, будет больше чем выигрыш от самих кэшей.
<СУБД сами имеют кэши>
Ну… можно, конечно, и отдать этот вопрос на откуп СУБД. Это уже тема выбора СУБД, которые поддерживает фреймворк. Другое дело, что вообще далеко не всегда есть желание/возможность у конечного пользователя разворачивать на локальной машине отдельную СУБД для использования локальной системы учета. Хорошо, что есть платформы, где это не обязательно.
У этого есть обратная сторона медали. Дело в том, что в современных СУБД реализовано огромное количество различных возможностей, вроде аналитических функций, рекурсий, замыканий (APPLY), представлений и т.п. И поэтому если реализовывать встроенную СУБД придется либо отказаться от этих возможностей (то есть выплеснуть вместе с водой и ребенка, как сделал 1С), либо все же реализовывать их, но такая задача по сложности сравнится с разработкой самой платформы.
А вот тут в корне не соглашусь. В случаях, когда в некоей таблице хранится действительно большое количество записей, наивно надеяться, что никто никогда не захочет плотно поработать с записями, листая таблицу и в хвост и в гриву.
Дело не в том, что никто не захочет, а что это будет достаточно не часто, а кэши придется поддерживать всегда. Поэтому затраты на их поддержание превысят выигрыш от этих кэшей.
кэши будут сбрасываться постоянно
можно не сбрасывать кэш, а обновлять тот элемент, о котором сообщил триггер. В 1С, например, можно оповещать об изменении только одного элемента
если реализовывать встроенную СУБД придется либо отказаться от этих возможностей (то есть выплеснуть вместе с водой и ребенка, как сделал 1С), либо все же реализовывать их
А Вы смотрИте на эти вещи проще. Если кому-то нужен локальный функционал, и мы даем такому клиенту возможность не разворачивать на машине полноценную СУБД, то пусть наше решение будет попроще. Ничего страшного в этом нет. Клиент согласится на урезанную версию, лишь бы не нагромождать у себя весь стек технологий.
Дело не в том, что никто не захочет, а что это будет достаточно не часто
Ок, принимается. Зачастую, проектируя какой-то фрагмент функционала, приходится отталкиваться от прогнозов относительно его нагруженности. И если предполагается, что вот в этой, грубо говоря, таблице будет много данных, но листать их вверх-вниз «будет достаточно не часто», то — да, кэши нужно отключать. В общем, фреймворк должен быть достаточно гибок, чтобы позволять использовать ту градацию функциональности, которая нужна в том или ином случае.
можно не сбрасывать кэш, а обновлять тот элемент, о котором сообщил триггер. В 1С, например, можно оповещать об изменении только одного элемента
Это как? СУБД будет уведомлять сервер приложений? Мы сейчас видимо о разных вещах говорим. Речь шла о кэшировании результатов в запросах динамических списков.
А Вы смотрИте на эти вещи проще. Если кому-то нужен локальный функционал, и мы даем такому клиенту возможность не разворачивать на машине полноценную СУБД, то пусть наше решение будет попроще. Ничего страшного в этом нет. Клиент согласится на урезанную версию, лишь бы не нагромождать у себя весь стек технологий.
Я про то что 1С возможно те же оконные функции не включили в язык запросов, потому как иначе их пришлось бы в файловой СУБД реализовывать, а это мягко говоря не тривиальная задача.
Это как?Платформа уведомляет открытые динамические списки о том, что изменились/удалились/появились определенные данные. В качестве данных может выступать ссылка на определенный элемент. И если эта ссылка у нас уже есть (запрашивать у СУБД значение ссылки не требуется), то СУБД в этом процессе совершенно не используется.
1С возможно те же оконные функции не включили в язык запросов
Мне это неизвестно. В 1С язык запросов, доступный разработчику сильно урезан, а запросы, которыми пользуется сама платформа — черный ящик. При желании можно воспользоваться инструментами СУБД, чтобы посмотреть, какие запросы посылает платформа к СУБД. Оставим использование платформой оконных функций для других публикаций. Думаю, в рамках обсуждения динамического вывода значительных объемов информации мы прояснили все мелочи :)
Платформа уведомляет открытые динамические списки о том, что изменились/удалились/появились определенные данные. В качестве данных может выступать ссылка на определенный элемент. И если эта ссылка у нас уже есть (запрашивать у СУБД значение ссылки не требуется), то СУБД в этом процессе совершенно не используется.
По сути это означает, что на сервере приложений идет инкрементальное обновление запроса (то есть представления)? Этого даже современные СУБД толком делать не умеют, а у 1С SQL на уровне 92 года, и рекомендации в стиле «не используйте подзапросы». Но в данном случае даже если это сделать, это будет экономией на спичках.
Подозреваю, что способ реализации этого механизма от релиза к релизу менялся, и сейчас еще находится не в финальном виде. Имхо, кэширование в 1С иногда было даже этакой «вещью в себе» и что-то, бывало, работало после обновления платформы в полную силу только после достаточного наполнения новых емкостей кэша. 1С'ники с некоторых пор спокойно к этому относятся. Примеров не приведу, но обсуждения коммьюнити на эту тему легко нагуглить.
Сейчас нет смысла обсуждать этот момент, поскольку, как, видимо, и IsFusion, платформа 1С 8 находится в состоянии активной эволюции.
Так или иначе, основные моменты, связанные с динамическим выводом мы обсудили, и я могу, собственно, что-то продемонстрировать…
Сейчас нет смысла обсуждать этот момент, поскольку, как, видимо, и IsFusion, платформа 1С 8 находится в состоянии активной эволюции.
Так или иначе, основные моменты, связанные с динамическим выводом мы обсудили, и я могу, собственно, что-то продемонстрировать…
СУБД в этом процессе совершенно не используетсяпоправочка: конечно, СУБД придется использовать, когда платформа будет обновлять кэш, реагируя на полученное оповещение.
Так. Реакция на местные обзоры lsFusion на небезызвестном форуме 1С'ников подутихла, и у меня есть время оставить тут для справедливости пример реализации в 1С подбор «а ля lsFusion» (хотя понятно, что реализация представленного кейса силами того или иного фреймворка не дает представляющему никаких интеллектуальных прав).
Итак, пример подбора. Прежде всего мне непонятно категоричное неприятие командой lsFusion самого принципа, навязанного платформой: список, динамически выводимый пользователю, служит для чтения некоторых данных, а не для их редактирования. Этот вопрос не раз поднимался толковыми и не очень мемберами на разных форумах, так что не стану сейчас подробно останавливаться на вычисляемых полях, блокировке редактируемых данных, событиях и триггерах — и других соображениях, исходя из которых авторы платформы 1С не включили в механизм динамического вывода т.н. поля ввода. Напомню лишь еще раз, что у платформы есть масса других элементов интерфейса, в т.ч. «а ля Excel», где возможен непосредственный ввод. В случае же с динамически выводимыми данными никто не мешает, если уж таково требование заказчика к интерфейсу, отображать более или менее продвинутое вспомогательное окно, предназначенное для ввода значения определенного типа — календарь, числовая клавиатура… Эта фишка не нова. Простейший пример — скрин поля ввода в PhpMyAdmin (собственно, что есть под рукой):
Так почему нельзя использовать что-то такое при вводе прямо в динамический список?
Собственно, исходя из этого постулата и опираясь на показавшееся мне логически верным описание одного из вариантов реализации требуемого подбора и пожелания лицезреть это:
не поленился набросать форму, аналогичную служившей примером в данной публикации:
Я посчитал, сколько строк кода получилось в вашем случае. Меньше ста.
Мне же для получения такого же результата пришлось пощелкать в wysiwyg-редакторе, написать кода немногим более 150-и строк, а потом еще поднастроить слегка внешний вид формы, чтобы вспомогательные элементы напоминали таковые в вашем примере. Вывод: в каких-то случаях скрипты на встроенном языке 1С сложнее, чем в lsFusion для достижения одинакового результата. Но точно нет такого алгоритма «а ля lsFusion», который бы никак нельзя было реализовать на 1С разумным количеством действий.
Но прежде хотелось бы все-таки обозначить свою позицию
Во-первых, у меня нет столь критичного отношения к вашим наработкам, как у некоторых адептов 1С, среагировавших на пару случаев подклейки к публикациям команды lsFusion тега «1С» и навязчивого сравнения вашего фреймворка с платформой 1С. То, что мы сейчас наблюдаем — и оголтелая критика, и предвзятое отношение, и нецензурные записи в вашей демо-БД, оставленные, вероятно, в том числе кем-то из 1С'ников — все это было неизбежно. Среди пользователей любого фреймворка найдутся и грамотные, сдержанные профессионалы, и импульсивные матерящиеся негативно настроенные мужики. И чем ниже порог вхождения в предмет, тем больше шансов пообщаться со вторыми. Вот порог вхождения в 1С — довольно низкий. Но все же откровенного хамства ни здесь, ни на других площадках авторы lsFusion пока не хлебнули. Высказывания, преимущественно — по существу.
Но ведь ваши представители подчеркивают, что порог вхождения для любого желающего в ваш фреймворк — значительно ниже, чем в разработку на 1С. Так что у вас самое интересное — маячит всей своей тушей на горизонте. Готовьтесь к общению на совершенно другом уровне :)
Во-вторых, споры, которые случаются сейчас между авторами одного фреймворка и пользователями другого — это, наверное, неправильно и несправедливо. Если уж строить спор — так между вашими специалистами и ведущими специалистами ООО «1С», хотя понятно, что и такой диалог был бы лишен смысла — уж слишком разные весовые категории.
В-третьих, сейчас, после череды ярких статей от вашей команды многие IT-шники, и многие 1С'ники в том числе, присматриваются к интересным наработкам из братской Беларуси с целью ознакомиться с практической ценностью представленного функционала, ибо как раз 1С'ники всегда отличались в своей работе, в автоматизации, особенным стремлением любым способами удешевить разработку вспомогательных механизмов (без них никуда), трезвым и адекватным отношением к любым языкам и фреймворкам. А высшая ступень специалиста по платформе 1С (имею ввиду ЭТВ) прямо требует знаний в самых разных областях.
Так вот, если вы сейчас продолжите презентации в стиле «вот как мы можем, и это лучше, чем у 1С», то такая подача, как уже неоднократно отмечалось, только испортит позитивный интерес. Она не даст вам ощутимых очков, но автоматически задвинет в ряд «еще одних убийц 1С», а сколько их уже было? И где они сейчас?
Но ведь ваши представители подчеркивают, что порог вхождения для любого желающего в ваш фреймворк — значительно ниже, чем в разработку на 1С. Так что у вас самое интересное — маячит всей своей тушей на горизонте. Готовьтесь к общению на совершенно другом уровне :)
Во-вторых, споры, которые случаются сейчас между авторами одного фреймворка и пользователями другого — это, наверное, неправильно и несправедливо. Если уж строить спор — так между вашими специалистами и ведущими специалистами ООО «1С», хотя понятно, что и такой диалог был бы лишен смысла — уж слишком разные весовые категории.
В-третьих, сейчас, после череды ярких статей от вашей команды многие IT-шники, и многие 1С'ники в том числе, присматриваются к интересным наработкам из братской Беларуси с целью ознакомиться с практической ценностью представленного функционала, ибо как раз 1С'ники всегда отличались в своей работе, в автоматизации, особенным стремлением любым способами удешевить разработку вспомогательных механизмов (без них никуда), трезвым и адекватным отношением к любым языкам и фреймворкам. А высшая ступень специалиста по платформе 1С (имею ввиду ЭТВ) прямо требует знаний в самых разных областях.
Так вот, если вы сейчас продолжите презентации в стиле «вот как мы можем, и это лучше, чем у 1С», то такая подача, как уже неоднократно отмечалось, только испортит позитивный интерес. Она не даст вам ощутимых очков, но автоматически задвинет в ряд «еще одних убийц 1С», а сколько их уже было? И где они сейчас?
Итак, пример подбора. Прежде всего мне непонятно категоричное неприятие командой lsFusion самого принципа, навязанного платформой: список, динамически выводимый пользователю, служит для чтения некоторых данных, а не для их редактирования. Этот вопрос не раз поднимался толковыми и не очень мемберами на разных форумах, так что не стану сейчас подробно останавливаться на вычисляемых полях, блокировке редактируемых данных, событиях и триггерах — и других соображениях, исходя из которых авторы платформы 1С не включили в механизм динамического вывода т.н. поля ввода. Напомню лишь еще раз, что у платформы есть масса других элементов интерфейса, в т.ч. «а ля Excel», где возможен непосредственный ввод. В случае же с динамически выводимыми данными никто не мешает, если уж таково требование заказчика к интерфейсу, отображать более или менее продвинутое вспомогательное окно, предназначенное для ввода значения определенного типа — календарь, числовая клавиатура… Эта фишка не нова. Простейший пример — скрин поля ввода в PhpMyAdmin (собственно, что есть под рукой):
Так почему нельзя использовать что-то такое при вводе прямо в динамический список?
Собственно, исходя из этого постулата и опираясь на показавшееся мне логически верным описание одного из вариантов реализации требуемого подбора и пожелания лицезреть это:
предполагается, что надо руками хранить, что пользователь изменил, и при открытии диалога дополнительно проверять не измененные ли это данные. Плюс я так понимаю это надо как-то в запросе динамического списка учитывать (он вообще к таблицам значения обращаться умеет?), и вручную заставлять этот динамический список обновляться при изменении таблицы значений с изменениями. В любом случае вы опять-таки представляете сколько кода при этом будет?
не поленился набросать форму, аналогичную служившей примером в данной публикации:
Я посчитал, сколько строк кода получилось в вашем случае. Меньше ста.
Мне же для получения такого же результата пришлось пощелкать в wysiwyg-редакторе, написать кода немногим более 150-и строк, а потом еще поднастроить слегка внешний вид формы, чтобы вспомогательные элементы напоминали таковые в вашем примере. Вывод: в каких-то случаях скрипты на встроенном языке 1С сложнее, чем в lsFusion для достижения одинакового результата. Но точно нет такого алгоритма «а ля lsFusion», который бы никак нельзя было реализовать на 1С разумным количеством действий.
Прежде чем ответить подробнее, можете привести эти 150 строк кода здесь под катом? Ну и запросы сгенерированные или написанные. И xml формы из EDT было бы вообще круто, но не обязательно.
Приторможу с этим. Есть риск погрязнуть в упреках относительно оптимальности алгоритмов или самого принципа, с помощью которого это было реализовано. Я все-таки не тру-программист, и код был написан, в некоторый степени, впопыхах. В т.ч. без попыток как-то сжать его. Свои же коллеги 1С'ники могут меня раскритиковать, как это уже случилось под конец обсуждения вашего продукта на другом ресурсе. Замечу лишь, что считаю себя немножко педантом. Во всяком случае, качество моего кода в моей команде иногда ставят в пример. И озвучу механику: для реализации такого подбора я просто храню две таблицы: одна, СтрокиЗаказа «живет» только на клиенте и выводится на форму, а другая, «таблица значений с изменениями» — только на сервере. И каждый раз, когда пользователь что-то вводит, обе таблицы синхронизируются. Контекстных серверных вызовов нет, т.е. ни одна таблица целиком с клиента на сервер или обратно не гоняется. Аа, ну и плюс есть динамический список, вот он порциями обновляется с сервера.
Приводить ли код, и как вообще реагировать на ваше продвижение — жизнь покажет.
Приводить ли код, и как вообще реагировать на ваше продвижение — жизнь покажет.
У вас количество вводится через диалог. Это не тоже самое, так как требует большего нажатия кнопок пользователем. Сделайте, пожалуйста, чтобы количество вводилось как на строке заказа.
Не вижу смысла. Этот вопрос уже муссировался сто раз. Чуть выше скриншот аналогичного всплывающего окна в phpmyadmin.
Предпочитаю остановиться на том варианте, который я продемонстрировал, и признать, что в несущественных деталях интерфейс 1С все-таки принципиально отличается, и с этим ничего нельзя поделать средствами платформы (обходные костыли есть, но это не обсуждается). После ввода цифры пользователю придется нажать еще одну клавишу — это закроет всплывающее для ввода цифры окно.
Но ведь и в lsFusion, и в Excel чтобы завершить ввод в ячейку нужно обязательно что-то еще нажать!
В несущественных настолько, что я не понимаю, зачем Вы этот момент акцентируете до сих пор.
Предпочитаю остановиться на том варианте, который я продемонстрировал, и признать, что в несущественных деталях интерфейс 1С все-таки принципиально отличается, и с этим ничего нельзя поделать средствами платформы (обходные костыли есть, но это не обсуждается). После ввода цифры пользователю придется нажать еще одну клавишу — это закроет всплывающее для ввода цифры окно.
Но ведь и в lsFusion, и в Excel чтобы завершить ввод в ячейку нужно обязательно что-то еще нажать!
В несущественных настолько, что я не понимаю, зачем Вы этот момент акцентируете до сих пор.
Не очень понимаю, причем здесь вообще phpMyAdmin. Просто признайте, что в 1С так сделать нельзя, или напишите как и поделитесь кодом.
Насколько это удобно, какой код проще, существенность или несущественность — каждый решает сам для себя.
Насколько это удобно, какой код проще, существенность или несущественность — каждый решает сам для себя.
Согласен с этим. Уже признал, даже подчеркнул, что признал (см. чуть выше).
Смотрите, основной use case в том же Excel при таком вводе будет следующим:
В вашем случае получается как минимум на одну клавишу больше (если не 2)
- Нажал 3
- Нажал вниз или вверх
- Нажал 4
- Нажал вниз или вверх
- и т.д.
В вашем случае получается как минимум на одну клавишу больше (если не 2)
Нажал 3
Нажал вниз или вверх
Нажал 4
Нажал вниз или вверх
Это справедливо только если пользователь намерен вставлять количество (какое-то значение в рамках одной колонки) в каждую строку таблицы по порядку.
Но на практике пользователь выбирает, просматривая строки (и какую-то вспомогательную информацию, находящуюся в других колонках или где-то еще), куда ввести количество, и вводит его не в каждую строку.
В любом случае я могу запрограммировать при нажатии Tab после ввода сразу же начало ввода в следующую строку. А при нажатии Enter — просто спозиционироваться на следующей строке (закрыв окошечко ввода). И будет заказчику
- Нажал 3
- Нажал Tab (или Shift+Tab, если надо начать ввод в предыдущую строку)
- Нажал 4
- Нажал Tab
- Нажал 8
- Нажал Enter, чтобы завершить ввод количеств, сразу попасть в следующую строку и при необходимости перейти мышкой или клавиатурой еще куда-то
- <...>
Это все равно будет работать не так как в Excel, а с всплывающим окном и переходом именно на следующую строку. Соответственно клавиши вверх и вниз также работать не будет. Хорошо это или плохо — субъективный вопрос. Каждый решает для себя.
Конечно, это будет работать не так, как в Excel. В Excel вообще нет динамического вывода данных. А вот в lsFusion есть динамический вывод, и указание количества прямо в этом «выводе». Я лишь продемонстрировал, что подобное можно сделать и в 1С без проблем.
Что касается клавиш вверх-вниз, в 1С они уже зарезервированы — по «вниз» может выпадать вспомогательный список значений. Значений, которые может подсказывать пользователю система, отталкиваясь, например, от остатков или истории выбранных для этой позиции значений. Или исходя из любых других алгоритмов. А «вверх» вызывает маленький калькулятор (или что-то еще в зависимости от типа данных в поле ввода).
Поэтому для перехода/начала ввода в следующую строку можно использовать Tab.
В lsFusion нет таких возможностей. Зато свободен «Вниз» для перехода к следующей строке. А в 1С — можно использовать Tab. Там одна кнопка, а тут — другая. Вообще проблемы никакой не вижу. Слишком мелкий вопрос, чтобы применять к нему «хорошо или плохо».
И пусть никого не смутит Ваше «с всплывающим окном». На самом деле оно не всплывает, а немедленно «выскакивает» при выборе интересующей пользователя строки. Скорость «наколачивания» накладных в таком режиме ничем не будет отличаться от скорости «наколачивания» данных в том же Excel.
Что касается клавиш вверх-вниз, в 1С они уже зарезервированы — по «вниз» может выпадать вспомогательный список значений. Значений, которые может подсказывать пользователю система, отталкиваясь, например, от остатков или истории выбранных для этой позиции значений. Или исходя из любых других алгоритмов. А «вверх» вызывает маленький калькулятор (или что-то еще в зависимости от типа данных в поле ввода).
Поэтому для перехода/начала ввода в следующую строку можно использовать Tab.
В lsFusion нет таких возможностей. Зато свободен «Вниз» для перехода к следующей строке. А в 1С — можно использовать Tab. Там одна кнопка, а тут — другая. Вообще проблемы никакой не вижу. Слишком мелкий вопрос, чтобы применять к нему «хорошо или плохо».
И пусть никого не смутит Ваше «с всплывающим окном». На самом деле оно не всплывает, а немедленно «выскакивает» при выборе интересующей пользователя строки. Скорость «наколачивания» накладных в таком режиме ничем не будет отличаться от скорости «наколачивания» данных в том же Excel.
Может быть, даже, наоборот
учитывая, что «Excel в облаке» в виде тонкого клиента не реализована. Т.е. либо ставим Office локально, и все нагрузка при работе — на нашу локальную машину, и не дай Бог, чтоб она была недостаточно шустрая, либо работаем через браузер со всеми вытекающими, либо делаем что-то вроде RemoteApp, и юзеры путаются в файловых пространствах. А главное — весь список данных, а он может быть гигантским, Excel выводит перед пользователем единовременно. Поправьте меня, если я ошибаюсь, но и для Excel в облаке это заявление справедливо. О чем тут можно говорить?
Три поправочки.
Ыть, ну все, дорогой CrushBy из братской и бесконечно красивой Беларуси, я не представляю, как Вы теперь будете возражать. Мне не нравится спорить, и я делаю это разве что предварительно не поленившись проверить лично свои аргументы. Так можно долго муссировать этот вопрос, но я не успокоюсь, потому что уверен в своей правоте.
Уважаемая sergeevaira может сколько угодно критиковать форму подбора в одной из типовых конфигураций, но поверьте, тот способ выбран не потому, что платформа по-другому не умеет. Алгоритм подбора выстрадан десятилетиями опыта, который есть за плечами вендора, и тысячами мнений разношерстных пользователей. Кому не нравится — свои программисты корректируют согласно пожеланиям работодателя.
Сравнивайтесь с Microsoft или еще кем-то… а лучше — ну их всех. Давайте лучше параллельно развиваться дальше. Заказчиков на всех хватит. Меня вот заинтересовало мнение oldschoolgeek насчет task-based UI и современных подходов к построению CRUD интерфейсов. Действительно непонятно, что он имел ввиду. И качество «хотя бы» на уровне чего-то, даже Dynamics 365 — такое нам не надо. Уж двигаться вперед — так ориентируясь не на хотя бы, а на бест-практикс. Хотелось бы разузнать про современные тенденции. Скриншоты того же SAP'а ничего не дают. Мои коллеги и гугл мне не помогли. Может быть у Вас есть, чем поделиться? То, что у вас в демке — явно не ориентир, вы сами это признаете. Может еще есть идеи, как достичь уровня знаний oldschoolgeek?
- Какая-то анимация у окошка ввода все-таки есть. Но значение можно вводить немедленно после выбора строки. Его не съедят лангольеры :)
- Мне, на самом деле, неизвестно, может ли lsFusion, из коробки или будучи запрограммирована, показывать что-то для отдельно взятой ячейки, например калькулятор. Но если может — для этого тоже понадобится горячая клавиша. Желательно общеизвестная и удобно на клавиатуре расположенная. А их, что для lsFusion, что для 1С, не так много.
- На самом деле мне необязательно вызывать ввод для следующей строки именно по клавише Tab :) 1С позволяет использовать для этого много разных клавиш. Уж выберем с заказчиком, что ему по душе, из того, что предлагает платформа.
Ыть, ну все, дорогой CrushBy из братской и бесконечно красивой Беларуси, я не представляю, как Вы теперь будете возражать. Мне не нравится спорить, и я делаю это разве что предварительно не поленившись проверить лично свои аргументы. Так можно долго муссировать этот вопрос, но я не успокоюсь, потому что уверен в своей правоте.
Уважаемая sergeevaira может сколько угодно критиковать форму подбора в одной из типовых конфигураций, но поверьте, тот способ выбран не потому, что платформа по-другому не умеет. Алгоритм подбора выстрадан десятилетиями опыта, который есть за плечами вендора, и тысячами мнений разношерстных пользователей. Кому не нравится — свои программисты корректируют согласно пожеланиям работодателя.
Сравнивайтесь с Microsoft или еще кем-то… а лучше — ну их всех. Давайте лучше параллельно развиваться дальше. Заказчиков на всех хватит. Меня вот заинтересовало мнение oldschoolgeek насчет task-based UI и современных подходов к построению CRUD интерфейсов. Действительно непонятно, что он имел ввиду. И качество «хотя бы» на уровне чего-то, даже Dynamics 365 — такое нам не надо. Уж двигаться вперед — так ориентируясь не на хотя бы, а на бест-практикс. Хотелось бы разузнать про современные тенденции. Скриншоты того же SAP'а ничего не дают. Мои коллеги и гугл мне не помогли. Может быть у Вас есть, чем поделиться? То, что у вас в демке — явно не ориентир, вы сами это признаете. Может еще есть идеи, как достичь уровня знаний oldschoolgeek?
Уважаемый, PiotrLoginov
Я уважаю вашу основательность в этом вопросе, но, по-моему, Вы делаете из мухи слона. Статья была про один относительно небольшой аспект интерфейса. Кроме того, там нигде не было утверждения, что так сделать в 1С нельзя. Вот цитата:
Спор действительно бесполезный и бессмысленный. Как я уже много раз говорил, тут все субъективно. Единственное, чего не хватает для полной картины — это исходный код на 1С. Нам это интересно хотя бы для того, чтобы понимать как это работает в 1С и какие SQL запросы формируются (просто из любопытства).
К сожалению, это не может являться аргументом в предметном споре, пока мы не знаем кто и зачем страдал.
К сожалению, мысли читать не умею, а он на вопросы не ответил. Так что эти сокровенные знания останутся только с ним.
Что касается сравнений и критики — то это нормальная практика. Все в жизни познается в сравнении, и решение любой проблемы начинается с ее идентификации и признания. Главное, чтобы сравнение и критика были аргументированными. Лично мы только за то, чтобы на конструктивно критиковали. Это основа для того, чтобы становиться лучше.
Я уважаю вашу основательность в этом вопросе, но, по-моему, Вы делаете из мухи слона. Статья была про один относительно небольшой аспект интерфейса. Кроме того, там нигде не было утверждения, что так сделать в 1С нельзя. Вот цитата:
Впрочем, возможно в 1С можно реализовать и вышеописанную схему, но почему-то в типовых конфигурациях, которые доступны на сайте с демо-версиями используется другая.
Спор действительно бесполезный и бессмысленный. Как я уже много раз говорил, тут все субъективно. Единственное, чего не хватает для полной картины — это исходный код на 1С. Нам это интересно хотя бы для того, чтобы понимать как это работает в 1С и какие SQL запросы формируются (просто из любопытства).
Алгоритм подбора выстрадан десятилетиями опыта, который есть за плечами вендора, и тысячами мнений разношерстных пользователей.
К сожалению, это не может являться аргументом в предметном споре, пока мы не знаем кто и зачем страдал.
Может еще есть идеи, как достичь уровня знаний oldschoolgeek?
К сожалению, мысли читать не умею, а он на вопросы не ответил. Так что эти сокровенные знания останутся только с ним.
Что касается сравнений и критики — то это нормальная практика. Все в жизни познается в сравнении, и решение любой проблемы начинается с ее идентификации и признания. Главное, чтобы сравнение и критика были аргументированными. Лично мы только за то, чтобы на конструктивно критиковали. Это основа для того, чтобы становиться лучше.
см. выше
Мда. Сравнение форм подбора вне контекста алгоритмов работы пользователей с ИС — такое себе развлечение…
А можете уточнить, что Вы подразумеваете под «контекста алгоритмов работы пользователей с ИС»?
В статье четко указаны как минимум 3 кейса: ручной ввод документов заказов на закупку, продажу и изменения остатков. Конкретно в них, такой способ построения интерфейсов является более удобным, чем в 2х других случаях.
В статье четко указаны как минимум 3 кейса: ручной ввод документов заказов на закупку, продажу и изменения остатков. Конкретно в них, такой способ построения интерфейсов является более удобным, чем в 2х других случаях.
Это не кейсы, вы рассматриваете, куда применить ваше готовое решение, а не выводите преимущество именно вашего решения в конкретном кейсе. Чтобы это было кейсом надо прописать все действия пользователя, кто он, каковы его основные обязанности, каковы требования к скорости ввода, почему ввод нельзя организовать иным, отличным от ручного, способом, сколько строк в заказах, и т.д.
Если честно, то даже не знаю, что на это ответить.
Я конечно понимаю, что из-за ограничений платформ 1С, ее разработчикам всегда приходится убеждать пользователей в ответ на их пожелания, что им этого не надо. Для этого, например, они просят их написать подробное ТЗ, при этом задавая кучу бессмысленных вопросов и требуя указать несущественные детали. И все это в расчете на то, что пользователь просто отстанет.
Большинство наших пользователей считает такой механизм подбора гораздо удобнее, чем в 1С и Microsoft Dynamics. Я понимаю, что это субъективно, так что давайте на этом остановимся. Если вы считаете по-другому, то можете также написать статью, изложив и аргументировав Вашу точку зрения.
Я конечно понимаю, что из-за ограничений платформ 1С, ее разработчикам всегда приходится убеждать пользователей в ответ на их пожелания, что им этого не надо. Для этого, например, они просят их написать подробное ТЗ, при этом задавая кучу бессмысленных вопросов и требуя указать несущественные детали. И все это в расчете на то, что пользователь просто отстанет.
Большинство наших пользователей считает такой механизм подбора гораздо удобнее, чем в 1С и Microsoft Dynamics. Я понимаю, что это субъективно, так что давайте на этом остановимся. Если вы считаете по-другому, то можете также написать статью, изложив и аргументировав Вашу точку зрения.
<...> они просят их написать подробное ТЗ, при этом задавая кучу бессмысленных вопросов и требуя указать несущественные детали. И все это в расчете на то, что пользователь просто отстанет
Уверен, халтурщиков и профанов везде хватает. Возможно, Вы также дадите право распространять ваш продукт интегратору «Мы внедряем lsFusion в городке N», а он будет городить непонятные велосипеды, чихать на конечного юзера, плавать в предметке и функционале фреймворка… А Вы и знать не будете. Когда сеть франчайзи разрастется, за всеми не уследите.
А по поводу
ограничений платформ 1Смне казалось, мы уже поставили точку в этом вопросе. Не так страшен дьявол, как Вам сначала показалось. Все реализуемо. Была бы квалификация.
Уверен, халтурщиков и профанов везде хватает. Возможно, Вы также дадите право распространять ваш продукт интегратору «Мы внедряем lsFusion в городке N», а он будет городить непонятные велосипеды, чихать на конечного юзера, плавать в предметке и функционале фреймворка… А Вы и знать не будете. Когда сеть франчайзи разрастется, за всеми не уследите.
Да, это проблема любой франшизы (не только в 1С и не только в программировании).
мне казалось, мы уже поставили точку в этом вопросе. Не так страшен дьявол, как Вам сначала показалось. Все реализуемо. Была бы квалификация.
Ограничения есть в любых технологиях. Но почему-то в основном только 1С-программисты начинают на эти ограничения задавать вопросы в стиле «А зачем ?» и утверждать, что это никому не надо. Остальные как правило относятся к этому более спокойно.
Точка будет поставлена тогда, когда будет исходный код. Только тогда будет понятно насколько страшен дьявол. И на ассемблере можно реализовать, что угодно. Как просто сделать редактируемый динамический список так никто и не сознался.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Строим интерфейс по вводу документов через подбор