В общем интересная задача.
Условия:
Компания предоставляет разные юр услуги.
На сайте на каждую услугу необходима форма заказа.
Все услуги имеют разный набор аттрибутов.
Есть зависимые аттрибуты: например, стоимость услуги зависит от срока выполнения и количества копий документов (цена=стоимость*количество*срок).
В заказ можно добавить несколько услуг.
И вот какая задача:
Нужно сделать конструктор, чтобы контент менеджер сам добавлял на сайт услуги и описывал их свойства. На основе этих свойств будут строиться формы на страницах услуг. При заполнении этих форм данные будут сохранятся в заказе.
Сначала я хотел делать отдельную таблицу под динамические поля (название, тип, код). Но еще непонятно, как делать зависимости полей друг от друга, куда записывать связи и формулы подсчета.
Потом подумал, может просто сделать модель услуги (название, описание), и в описании в формате json описывать все необходимые свойства услуги, связи, функции. А во фронтенде (например, через Angular) парсить json и строить формы для заказа.
А если понадобится новая услуга, то программно менять файл json?
По-моему, лучше через БД.
Таблицы: Услуги, Атрибуты, УслугиАтрибуты, Отчеты, ОтчетыЗначенияАтрибутов
Что касается зависимостей, то прежде, чем проектировать, надо рассмотреть варианты, какие типы зависимостей есть. Только арифметические? Атрибуты на форме показываются всегда или может быть так, что некоторые атрибуты показываются только если указано некоторое значение пред атрибута?
Например, можно завести в таблице Атрибуты поле Зависимость
и писать туда что-нибудь типа(A20 + A30) - A40/2, цифры после A - ид атрибутов
> А если понадобится новая услуга, то программно менять файл json?
В том то и дело, что не надо лазить в код. json описание хранится в поле модели "Услуга" в базе данных. И меняется как текст через админку. Надо новую услугу внести, зашли в админку, создали новую запись в БД: заголовок "Выписка ЕГРЮЛ", описание "{fields: [{title: "ИНН", name: "inn", type: "string", size: "12"}, {...}]}"
Алексей Свечкарь: Хранение json в поле БД нарушает ее целостность, хотя, не спорю, многие так делают, а в нек БД даже спец тип поля есть. Лично я бы делал наоборот, хранил данные в БД, а если на клиенте нужен JSON, то сделал бы типа веб-сервиса, который на основе переданных параметров генерил JSON из базы.
>>>json описание хранится в поле модели "Услуга" в базе данных. И меняется как текст через админку.
Получается, что новое свойство может добавить только программист, вряд ли обычный контент менеджер знает, что такое json и с чем его едят
для любой админки нужна инструкция + тренинг. даже если я покажу менеджеру форму из 5 полей вместо текстового поля с json, вряд ли он сразу поймет как описывать услугу. И потом поля могут быть не простыми: например, поле выбора срока выполнения с соответствующей стоимостью. Это еще одну таблицу для таких полей делать, или в описании поля значения через запятую прописывать?
Вот например,
{
title: "Кадастровый паспорт",
deadline:
title: "Срок выполнения",
type: "select",
select: [{
title: "В течении суток",
price: 500
},
{
title: "В течении часа",
price: 1700
}]
...
}
Как такое свойство уложить в таблицы? Причем это свойство является зависимостью для расчета стоимости.
Алексей Свечкарь: Это понятно, что тренинг нужен всегда. Но, одно дело, учить менеджера ставить галочки и нажимать кнопочки, совсем другое - нагружать его техническими деталями, заставлять разбираться его в непонятных текстовых форматах. В одной конторе, где я работал, девушку, далекую от IT, напрягли править какие-то xml, получалось у нее через раз, все равно xml часто был невалидным и приходилось активно ей помогать.
Представьте, каким будет SQL запрос для формирования json. Даже если составлять запрос на уровне приложения через модель услуги. И какая будет скорость рендеринга страницы с формой услуги. Фронт будет ожидать json описания, потом парсить и формировать html. Может я сгущаю краски, и, как говорится, глаза боятся, а руки делают :). Просто я хотел избежать кучи служебных таблиц. Думал, может более изящное решение есть.
Алексей Свечкарь:
>>>Представьте, каким будет SQL запрос для формирования json
Сложно возразить: джоинов и подзапросов будет порядком, придется колдовать с индексами, вьюхами, времянками и т д.
Можно немного облегчить: не генерить json на лету при работе посетителя с формой, а в админке сделать кнопку "Обновить файлы json" и нажимать ее после изменения полей из справочников.
да, вот как вариант! не писать json в текстовом редакторе, а сделать некий визульный конструктор, который будет строить json. Тогда контент менеджеру не придется руками писать. Тогда мы приходим к варианту, что куча таблиц не нужна. нужно написать конструктор для json, а после нажатия кнопки код json будет сохраняться в текстовом поле.
Генерация файла - дело ненадежное, права могут слететь, его может занять другой процесс, что-то глюканет и он сгенерится только до середины, да мало ли что. Когда он генерится на основе данных из базы - в аварийном случае можно просто нажать кнопку еще раз. Если же делать это минуя базу, то труды менеджера в случае чего пойдут насмарку и ему придется все конструировать заново.
А я про генерацию файла не писал. Я имел ввиду, что будет одна таблица "Услуги" с полями "Наименование", "Описание". В поле "Описание" будет сохраняться json текст, который сформируется при помощи визуального конструктора.
Простой
Средний
