"Со Spring и какими-либо ORM я никогда не работал"
вот мои подозрения и оправдались, вот он ключ
в данном случае бд это не живой организм с интеллектом а просто хранилище (ну почти), для инженера субд наверно звучит как кощунство.
MVC
M = model (модель хранения данных т.е. бд)
V = view (отображение информации на понятном простому человеку интерфейсе)
C = controller (бизнес логика и рендеринг данных из бд на экран силами ресурсного кода java с библиотекой spring)
а интерфейсы в java это совсем другая история, они тут не причем
нельзя уйти от концепции прямого отображения данных, нельзя отобразить функцию/формулу или что то еще, только явные реальные данные из бд.
ситуация следующая с данной функцией:
- если создать новый объект Vocation с диапазонам дат так чтобы текущая сразу в него попадала, реакции никакой, статус остается = 0, как только начинаю играть с датами (в бд, со стороны клиента такое делать нельзя, только создать новый диапазон или удалить его если требуется) то статус меняется как в условии функции
- если создать несколько "отпусков" в будущее для одного работника и попробовать поменять системную дату (current date по сути) так что бы она попадала в какой то из этих "отпусков" то смены статуса не происходит
alexalexes,
как же не должно
классы с аннотацией @Entity содержат поля ровно те что есть в таблице в бд и проецируются друг на друга (ORM)
на view (html в моем случае) я могу выводить данные на экран из этих самых полей из классов @Entity, иначе от куда что возьмется?
короче говоря конкретные данные из ячеек в бд выводятся на экран силами Spring.
alexalexes,
"Триггер тоже будет дергать аналогичную процедуру, но с частными параметрами"
не вопрос, я готов на это, пуст дергает. есть возможность показать как будет выглядеть триггер+функция для конкретно моего случая?
"Текущие статусы должны вычисляться налету в запросах или функции, а не храниться в базе."
может это если делать селекты непосредственно из бд.
в моем случае на основе этих полей выводится информация на экран, для обычных людей, про бд они даже не слышали, так же доступность к объекту сущности в зависимости от его статуса
alexalexes,
"А зачем в таблицу записывать статус, зависящий от текущей даты?"
так надо, и никак иначе, и появился он далеко не только потому что появилась связь employee - vocation, появился задолго до этого, и участвует он много еще где.
если я явно ошибся с выбором технологии как динамически и автоматически менять значение в колонке БД так и скажите, если не умеете создавать триггеры по таким условиям или вобще, не пишите пож что мне надо а что нет, совсем не профессиоанльно.
еще раз убеждаюсь что 90% ответчиков просто не читают вопрос и кусок кода который к нему прицеплен
как только в вопросе по JS прочиталось фраза "сохранить на странице состояние..." и т.п. все как инкубаторские начинают топить за LocalStorage, хотя тут он совсем ни к месту, и близко.
мне самому стыдно что я сам так долго не смог найти решения, а оно было плевым
удачи в гуглении!
th:selected просто сократит код в html
в контроллере все равно придется получать текущее состояние профессии, этого я и хочу избежать
а собственно где и как тут применить field?
да он что есть что его нету этот selected, конкретно механику html не объясню я ее не знаю
а вот если к чекбоксам прибавить checked, то на странице обновления данных, где бы галки не стояли, проставятся все
я эти варианты уже испробовал
вот как сделал я, и пока этим пользуюсь
в контроллере собирается коллекция всех профессий
далее, у данного объекта я беру текущую профессию (currentProfession см на скрине, вот он как раз selected)
далее из коллекции профессий удаляется текущая профессия, что бы они не дубл в выпадающем списке select, и все
но этот как то костыльно
только с полями 005 и 009, и все
все остальное подгружается корр, сравните скрины Просмотр данных и Обновеление данных, все что заполнено и сохранено все подгружается
вот, к примеру, поле 008 дата не так давно вело себя так же, но я нашел рабочий скрипт, немного его адаптировал и дата теперь подгружается та что была сохранена, вне зависимости какой из объектов (ID) из бд отображается
все html стандартные, с jsp (но это уже устаревшее от Spring) эффект будет тот же. все чекбоксы, радиобаттоны и селекты сбрасываются по умолчанию.
вобще все нормально работает кроме вот таких вот html прибамбасов
пример кода для поля 005
th: - это надстрой thymeleaf для динамики отображения данных, html как бы каркас, на одной странице отображаются разные объекты одного типа, из БД
никаких AJAX и прочих надстроек
только bootstrap для визуал (судя по скринам)
ед JS скрипты это только сортировка столбцов и поиск по ним, на первом скрине видно
после нажатия кнопки ОК все сохраняется и перебрасывает в меню Просмотр данных, кнопка Отмена делает тоже самое только ничего в БД не сохраняет (не обновляет)
по порядку:
вот главное меню отображения объектов из БД
далее, если нажать на кнопку "Просмотр" мы попадаем в меню просмотра данных (ID 26)
и через это меню (и только через него) можно попасть нажав на кнопку "Править" в меню Обновления данных объекта (опять ID 26)
поле 005 это селект - выбираем из выпадающего списка
поле 009 это чекбокс - ставим глаки где надо
все остальное заполняем и т.д.
нажимаем "ОК" и все сохраняется в БД как надо, все норм.
но если снова нажать кнопку "Править", то поля 005 и 009 сбрасываются, т.е. 005 селект переход на первое значение из списка, а 009 все галочки исчезают
никто и ничто это специально не сбрасывает в браузере, так оно работает по умолчанию, если не использовать JS фиксики или не колдовать на стороне сервера (что я сделал но меня это не устраивает)
я находил JS скрипты которые сохраняют выбранные данные (005 и 009 в моем случае) когда я захожу стр Обновления данных после их сохранения, но! теперь внимание! если после этого я зайду на стр Обновления данных другого объекта (ID 27 к примеру) то JS подгрузит данные предыдущего сохранения. это понятно? т.е. как бы с объекта ID 26, но это не так! он просто погружает сохраненные данные с предыдущей страницы Обновления данных, со стр HTML как таковой. вот и все.
полноценное редактирование
у меня не форма как регистрация на сайте, что то там позаполнял, проскочил каскадно и все. нет.
у меня формы отображения множества объектов с возм их редактирования (я не зря акцентировал внимание на ID), все хранится в БД, всё в нее записывается и загружается из нее как надо, все поля вариантов выбора селекта и чекбокса и радиобаттон подгружаются на стр редактирования данных (они иниц через цикл в HTML, не хардкодно прописаны), НО эти поля сбрасываются (не удаляются) на как только захожу на стр редактирования, не в БД, а на странице, т.е. решив поправить у объекта какое то одно поле, приходится заново выбирать сброшенный поля как было сохранено до захода на стр обновления, и это не дело.
а JS скрипты не багованные, они просто работают не "до конца" в моем случае, по этому ими не удалось попользоваться, т.к. на нашел нужного варианта.
вот мои подозрения и оправдались, вот он ключ
в данном случае бд это не живой организм с интеллектом а просто хранилище (ну почти), для инженера субд наверно звучит как кощунство.
MVC
M = model (модель хранения данных т.е. бд)
V = view (отображение информации на понятном простому человеку интерфейсе)
C = controller (бизнес логика и рендеринг данных из бд на экран силами ресурсного кода java с библиотекой spring)
а интерфейсы в java это совсем другая история, они тут не причем
нельзя уйти от концепции прямого отображения данных, нельзя отобразить функцию/формулу или что то еще, только явные реальные данные из бд.