Интерфейсы в кларионовских приложениях

[RaFaeL]

Рафаэль, мне кажется, у Вас ассоциация только со старой весией окна настройки параметров. Большинство окон у меня достаточно простые и выполняют строго отведенные им функции. Поэтому их достаточно много. Много кнопок и закладок в одном окне я видел как раз у Вас, поскольку Вы пытаетесь в один диалог вместить много разных функций. Соответственно, скорее всего, много ручного кода. Разные подходы.

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

[finsoftrz]

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

[RaFaeL]

Система прав доступа по тому же принципу, через таблицы идентификаторов сущностей, действий и возможностей. Поскольку как уже писал выше, обработка на указателях, куда передается идентификатор сущности, писать там особо нечего, все давно написано. Логирование с анализом изменений осуществляется триггерами на стороне SQL, там кларионовского кода вообще нет (кроме окна вывода таблицы изменений, собственно). Обо всём этом задумались еще лет так 15 назад, после чего вот в таком ключе и переписали. По юзабилити, конечно, местами есть вопросы, вида что проще пользователю на форме 5 текстовых полей заполнить, чем в списке 5 строк отредактировать, но зато он 6-е поле сам добавит, а у вас сам никак. Хотя я так понимаю у вас такая бизнес-модель просто, поля на формы вешать за деньги пользователей. Мне больше нравится коробки продавать и ничего не делать )

[finsoftrz]

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

[gopstop2007]

Система прав доступа по тому же принципу, через таблицы идентификаторов сущностей, действий и возможностей. Поскольку как уже писал выше, обработка на указателях, куда передается идентификатор сущности, писать там особо нечего, все давно написано. Логирование с анализом изменений осуществляется триггерами на стороне SQL, там кларионовского кода вообще нет (кроме окна вывода таблицы изменений, собственно). Обо всём этом задумались еще лет так 15 назад, после чего вот в таком ключе и переписали. По юзабилити, конечно, местами есть вопросы, вида что проще пользователю на форме 5 текстовых полей заполнить, чем в списке 5 строк отредактировать, но зато он 6-е поле сам добавит, а у вас сам никак. Хотя я так понимаю у вас такая бизнес-модель просто, поля на формы вешать за деньги пользователей. Мне больше нравится коробки продавать и ничего не делать )

Любопытно, у Вас в основном таблицы не более 4 полей, то есть рост данных и заполнение большей частью по "вертикали", а не по "горизонтали" и формат полей только строчный (возможно исключение - автоинкрементного), верно я понял?

[RaFaeL]

Софт для автоматизации оперативной работы, просто не по учёту. Про список товаров в окне выбора покупателя хотел бы посмотреть... Что касается анализа изменений, то вообще никак не анализируем, в целом такие вопросы у пользователей возникают крайне редко, это форс-мажорная ситуация, как правило, чтобы логи смотреть. Че их смотреть то? А окна новые не делаем, в том то и фишка

[RaFaeL]

Любопытно, у Вас в основном таблицы не более 4 полей, то есть рост данных и заполнение большей частью по "вертикали", а не по "горизонтали" и формат полей только строчный (возможно исключение - автоинкрементного), верно я понял?

Если это данные, которые именно данные, там сколько нужно полей по бизнес-логике, столько и будет полей, нужного типа и нужных связей, ключей и т.п.
Хотя не всё, для каждой сущности есть таблица дополнительных параметров (в нашей терминологии - признаки и свойства), это всё определяется пользователем. Количество значений не ограничено, любого типа (сейчас предусмотрено 9 разных типов)
Если это разные галочки да опции, то точно таблица значений параметров из небольшого количества полей

[finsoftrz]

С ходу, не сами товары, а их группы и какие-то свойства.

Выбор покупателя, как я это вижу.

[RaFaeL]

С ходу, не сами товары, а их группы и какие-то свойства.

Это отображение контрагентов по оборудованию, установленному у клиента (сверху переключатель, желтая коробка). Выбираете группу, затем снизу выбираете товар, справа будут контрагенты по этой номенклатуре. Думаю, вам надо просто переключить на группы (первая кнопка в верхнем ряду в этом окне), станет все понятнее

[finsoftrz]

Просто сравните. На втором скриншоте нет никаких нагромождений, только действительно нужная пользователю информация. Понятно, что диалог на первом скриншоте проектировался программистом, который не знает, что пользователю в этом месте может потребоваться, и сделал "с запасом", "на все случаи жизни". Если бы я своим пользователям такое вывалил, мне бы точно сказали, ты парень кукухой тронулся, мы будем тупо ошибаться при работе, а это легко выльется в потерю денег.

[finsoftrz]

С ходу, не сами товары, а их группы и какие-то свойства.

Это отображение контрагентов по оборудованию, установленному у клиента (сверху переключатель, желтая коробка). Выбираете группу, затем снизу выбираете товар, справа будут контрагенты по этой номенклатуре. Думаю, вам надо просто переключить на группы (первая кнопка в верхнем ряду в этом окне), станет все понятнее

Какому оборудованию? Я выбор нажал в отгрузочной накладной.

[finsoftrz]

Софт для автоматизации оперативной работы, просто не по учёту. Про список товаров в окне выбора покупателя хотел бы посмотреть... Что касается анализа изменений, то вообще никак не анализируем, в целом такие вопросы у пользователей возникают крайне редко, это форс-мажорная ситуация, как правило, чтобы логи смотреть. Че их смотреть то? А окна новые не делаем, в том то и фишка

У нас это востребованная функция. Полностью запретить изменения задним числом не получается. А контролировать хотят все, особенно те, чьи деньги в обороте крутятся. А вдруг там оператор со складом сговорились и начали сливать товары? Или менеджер начал со сбором денег у покупателей мухлевать.
Я не вижу ничего страшного в том, чтобы создавать новые оконные процедуры. Зачастую времени на их создание тратится меньше, чем на ручное кодирование в сложных окнах, плюс различный функционал автоматически подтягивается.

[RaFaeL]

Какому оборудованию? Я выбор нажал в отгрузочной накладной.

Ну так окно списка контрагентов то общее

В данном случае это демо-версия, в которой активированы все возможности программы. Разумеется, то окно, которое на вашем скриншоте, 99% пользователей не нужно. Поэтому вам нужно зайти в настройку интерфейса и снять вот эти галочки

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

[RaFaeL]

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

А вы сможете сделать настройками, как у меня? )

[finsoftrz]

Да, такое получилось.
А теперь давайте выведем задоженность по покупателю и разрешим редактировать информацию по нему. Желательно сразу и возможность посмотреть историю взаиморасчетов.