Custom Query (1135 matches)

Женя предлагает выводить на экран ссылки протоколы при открытии истории Платы

В БД изделий АДС в коде otk.php я обнаружил такой фрагмент:

if ($_POST['status'] == 'fail')
    $query = "UPDATE products set `otk` = ?, `mismatch` = 'yes' where `uid` = ?";
else if ($_POST['status'] == 'ok')
    $query = "UPDATE products set `otk` = ?, `mismatch` = 'no' where `uid` = ?";
else
    $query = "UPDATE products set `otk` = ? where `uid` = ?";

В чем смысл наличия третьей ветки условия (любой другой статус кроме "успешно" и "неуспешно")?

Единственно возможный статус кроме "успешно" и "неуспешно" - это "не контролировалось". Логика подсказывает, что изделие может перейти из состояния "не контролировалось" как в состояние "успешно", так и в состояние "неуспешно". Также можно представить, что изделие переходит из состояния "успешно" в "неуспешно" и наоборот (в результате повторного контроля ОТК). Но если изделие уже когда-то проходило контроль ОТК (то есть имеет статус "успешно" или "неуспешно"), то оно уже никак не может вернуться в состояние "не контролировалось" (так как это будет неправдой):

Мне кажется, что в случае получения в запросе любого статуса ОТК, отличного от "успешно" и "неуспешно", система должна ругаться и ничего не записывать в БД. Предлагаю изменить соответствующим образом последний вариант процитированного выше условия.

При клике по серийному номеру изделия на главной странице открывается страница его истории, на которой сначала расположена таблица, отображающая протоколы, а за ней - собственно таблица истории. При этом одна строчка таблицы протоколов имеет такую высоту, что выходит за пределы видимой на экране части страницы (и это при 27-дюймовом мониторе!), так что требуется прокрутить контент страницы чтобы только ее увидеть:

А если протоколов будет несколько?

Это хорошо, что теперь на странице истории сразу дается ссылка на протокол, однако мне кажется, что открывшего историю пользователя в первую очередь будет интересовать таблица с записями, и только во вторую (или даже более позднюю) - протоколы. Поэтому я считаю, что таблица истории важнее таблицы протоколов, и стоило бы скомпоновать страницу таким образом, чтобы для просмотра таблицы истории, по возможности, не требовались дополнительные действия. Мне кажется, что при более рациональном использовании площади страницы вполне можно скомпоновать отображаемую информацию так, что она вся уместится на одном экране даже при наличии нескольких протоколов, и пользователю не потребуется использовать прокрутку контента.

И, наконец, я заметил, что синий текст ссылки на фоне фотоизображения довольно трудно читается (см. приложенный скриншот).

Учитывая сказанное выше, предлагаю ряд улучшений:

• перекомпоновать страницу истории таким образом, чтобы сначала на ней располагалась собственно таблица истории, а уже после нее - таблица протоколов (как дополнительные материалы);

• уменьшить высоту строк таблицы протоколов - сделать их хотя бы приблизительно такой же высоты, как и строки в таблице истории (размер изображенной во весь экран иконки по-моему не пропорционален важности информации, которую она несет пользователю);

• сделать фон строк таблицы протоколов не чисто прозрачным как сейчас, а светлым полупрозрачным, примерно как и у таблицы истории;

• добавить перед таблицей протокола какой-то заголовок, из которого пользователю было бы понятно, что далее перечислены ссылки на найденные протоколы (в имени файла может не быть слова "протокол").

• Добавить в ответы сервера поле Cache-Control, в котором указать браузеру на необходимость валидировать документы через If-None-Match при каждой загрузке страницы, как это и было задумано изначально.