Цитата:
Сообщение от
wojzeh
коллега, спасибо за отзыв, но нельзя ли конкретизировать вашу критику?
в каком месте данный проект противоречит идеологии системы?
в чём собственно, на ваш взгляд, заключается эта самая идеология?
какие есть претензии к коду?
какие есть претензии к функциональности?
какие есть замечания по части интерфейса и удобства работы с формой?
Разрешите мне высказать свое личное мнение в плане неудобств без каких-либо дополнительных претензий/критик и т.п. Собственно говоря критика в первую очередь основана на том, что аналогичный инструмент, но без массового изменения данных (т.е. только по одной записи) я видел в другом исполнении.
Код не смотрел, ориентируюсь исключительно на скриншот, т.е. пытаюсь из себя представить некоего консультанта - пользователя данного инструмента.
1. Способ выбора таблиц.
В Аксапте контролька List используется на порядок реже контрольки Grid. И в ряде мест, где используется List я очень скучаю по Grid-у с его штатными возможностями фильтрации, сортировки, перестановки и скрытия столбцов.
На скриншоте реализована только фильтрация таблиц, причем с начала названия. Т.е. фильтрация у меня уже предопределена без возможности изменения. А вот мне внедренцы сделали табличку - которая в меню выведена в клиенты, поставщики и запасы. Какой у нее префикс (Cust/Vend/Invent)? Я не знаю. Но я могу ее найти как *MyTable*.
Далее. Название таблицы в коде и название ее в пункте меню - вещи разные. Даже в английском языке. Мне как консультанту неизвестно название таблицы в АОТе. Но я легко могу посмотреть Label таблицы. Достаточно нажать кнопку Расширенный фильтр (Ctrl+F3).
Как может консультант найти нужную ему таблицу по ее Label ?
2. Фильтрация таблиц по группам.
Мне как-то не привелось столкнуться с аккуратным расставлением этого свойства при внедрении. В стандарте - его стараются придерживаться - но тем не менее - при поиске таблицы - я обычно меньше всего думаю (может просто привык) о том к какой группе ее могли бы отнести. Фактически - вместо того, чтобы дать инструмент фильтрации в гриде сделан навязанный жесткий фильтр, который не покрывает мои потребности фильтрации.
3. Способ выбора полей.
К всему перечисленному выше добавляется еще тот факт, что если таблицы имеют префикс, относящий их к определенному модулю и какая-нибудь табличка - типа строки складского журнала наверняка имеет префикс Invent (т.е. данный инструмент позволяет сократить перечень таблиц, если я введу Invent) - то в случае полей такого правила нет и фильтр по началу названия поля абсолютно бесполезен.
Более того, поля более необходимо фильтровать по названию (Label), т.к. в интерфейсе label таблицы как правило не виден - т.к. его перекрывает label от пункта меню или дизайна формы. А вот label поля виден во всей красе по умолчанию везде, где его не переопределили на форме, что бывает достаточно редко.
4. Фильтрация полей по системным.
Тут фильтрация обоснована, т.к. она позволяет скрыть служебные поля. Хотя опять-таки - если уж предлагается фильтрация по названию поля из АОТ - то пользователь уж точно знает какие поля системные и смысла их фильтровать я не вижу
5. Изменение значений.
Изменять можно только строковые поля как я понял? А как же лукап? Я что - не могу выбрать значения из лукапа? (который строится в зависимости от EDT+Relation на таблице)
А числовые поля/денежные/дата-время (с календариком) и енумы (выбор из списка) ? Я хочу, чтобы механизм смены значения был максимально приближен к стандартному (енумы выбирать из списка, дату вводить из календарика, строковые данные вводить из лукапа и т.д.)
А при изменении отрабатывает update или doupdate? Например при правке InventTrans нужна отработка именно update, т.к. он синхронизирует еще и InventSum. А при правке CustTable к примеру совершенно необязательно чтобы отрабатывал код по синхронизации с smmBusRelTable, т.е. нужна отработка doupdate.
А поля modified* меняются при смене значения? А то к примеру мне нужно поменять одно поле в справочнике - и сразу я становлюсь автором изменений (может это и наоборот правильно).
А события/журнал БД при изменении работает? А то (возможно) я могу захотеть, чтобы на время изменений события не генерились. Я ж все ж консультант, а не рядовой пользователь.
6. Общее замечание по использованию.
Обычно требуется инструмент изменения данных в конкретной глючной записи. Т.е. система нештатно отработала и мы вручную подкорректировали неверно записанное значение.
Я осознанно опускаю понятие аудиторского следа, т.к. использование данного инструмента явно не предполагает использование аудиторского следа в рамках одной базы (к примеру инструментом можно пользоваться на тестовой БД)
Что видел я в плане смены значений:
Форма в стиле "Паспорт записи списком" - представляет собой грид из 3-полей - название поля (label), название поля (AOT), значение. При этом значение можно менять и работают все лукапы/енумы/календарики.
Форма простая, но позволяет сортировать/фильтровать по полям (label+name) штатным способом в гриде. Не позволяет правда менять данные массово.