Хранение в БД версий шаблонов договоров? (не бейте ногами, подробности в описании)

blnk

Новичок
Уважаемые аборигены. Научите уму-разуму.

Что имеем (как умеем): ООП, MVC, бд (SQL), подключаемый шаблон договора во view.

Собственно вопрос: Есть противоречивое желание хранить каждую новую редакцию договора в БД. Со всеми мелочами типа доступа для редактирования в cms, контроля последних изменений и прочих бонусов.
НО, при таком подходе вся идея mvc летит в тартарары. Как и где в таком случае вставлять динамические данные (фио, и прочее), которые нужны в теле договора? Где подключать шаблон? И еще тележка других вопросов, которые говорят о том, что открывается портал в волшебную страну невероятного по своей удивительности говнокода?

В общем вопрос не столько технический, сколько по архитектуре: как правильно реализовать хранение нескольких версий одного и того же шаблона в логике mvc?
 

fixxxer

К.О.
Партнер клуба
А причем тут MVC?
В MVC отдельно выделяется то, что отвечает за пользовательский интерфейс. Договор - это не пользовательский интерфейс, это самая что ни на есть бизнес-логика. Вот его рендеринг в разные форматы по желанию пользователя - это уже, возможно, интерфейс, да и то - it depends
 
Последнее редактирование:

blnk

Новичок
Вот его рендеринг в разные форматы по желанию пользователя - это уже, возможно, интерфейс, да и то - it depends
Речь о рендеринге и есть. Не хранить же шаблон с переменными в бд?
 
Последнее редактирование:

fixxxer

К.О.
Партнер клуба
Ну то есть есть шаблон договора, клиент, для которого надо сгенерировать договор, и целевой формат, так?
Что-то типа:
PHP:
$contractTemplate = $contractTemplateRepository->find($contractTemplateId);
$pdfContractRenderer = $contractRendererFactory->create(Format::PDF);
$contract = $pdfContractRenderer->render($contractTemplate, $customer);
$response->sendFileBlob($contract);
А уж где хранить contractTemplate, в базе, в файликах, или, там, в git'е - вопрос десятый.
 

blnk

Новичок
Ну то есть есть шаблон договора, клиент, для которого надо сгенерировать договор, и целевой формат, так?
Так.
Меня смущает только, что при предложенном варианте рендер идёт в контроллере. То есть, если contractTemplate хранится в базе >> после получения мы его ренедрим в котроллере >> результат передаём во view. То есть если я правильно понимаю, view получает уже готовый договор и больше ничего не делает. У меня вызывает некоторый диссонанс то, что шаблон для отображения по сути берётся со стороны модели и на стороне контроллера и модели доводится до нужной формы. Разве это не ломает логику разделения отображения и логики? (извините за тавтологию).

Просто сейчас у меня условный contractTemplate - это файл во view в который передаются данные пользователя, и рендерится он вместе со всей вьюхой разом.
 
Последнее редактирование:

blnk

Новичок
И сопутствующий вопрос: за хранение шаблона с php кодом (переменные, if, foreach) для последующего рендеринга разве по рукам не бьют?
 

fixxxer

К.О.
Партнер клуба
Меня смущает только, что при предложенном варианте рендер идёт в контроллере.
Не рендер, а вызов рендерера. Эм, ну так в любом фреймворке в контроллере какой-нибудь $this->renderTemplate('template.twig', $bindings), какая разница.

У меня вызывает некоторый диссонанс то, что шаблон для отображения по сути берётся со стороны модели и на стороне контроллера и модели доводится до нужной формы.
Ну так унеси эти три строчки кода в сервис, и не будет смущать. Я, правда, смысла не вижу.

модели доводится до нужной формы
Что-что? :)

шаблона с php кодом
А нахрена там шаблон с php-кодом? Там ж просто подстановка плейсхолдеров. Я даже цикл с трудом представляю себе в договоре, в моем понимании это тупо strtr(). Ну... Можно какой-нибудь mustache взять, скажем. Или xml+xslt, если и правда там нужна гибкость какая-то.
 

blnk

Новичок
Не рендер, а вызов рендерера. Эм, ну так в любом фреймворке в контроллере какой-нибудь $this->renderTemplate('template.twig', $bindings), какая разница.
Ну да. Ясно.

Неудачно выразился. Имел ввиду: доводит до нужной формы, конечно, контроллер, но если нужно, например, преобразовать сумму в сумму прописью, он отправляет число в модель, получает ответ и его вставляет в договор. Это не правильно?

Ну так унеси эти три строчки кода в сервис, и не будет смущать.
Я тут немного о другом. Понятно, что вызов рендера в контроллере. Просто видимо привычка контролировать контент в шаблоне во view сбивает меня с толку. Видимо, ничего страшного в том, что он подготавливается в контроллере и передаётся во view уже статическим и подготовленным нет.

По поводу сервиса: думаю еще один слой скорее создаст больше вопросов, чем поможет на данном этапе. Слишком мало знаю. Тут сначала бы прийти к пониманию где кончается контроллер и начинается модель и что делать "толстым".

А нахрена там шаблон с php-кодом? Там ж просто подстановка плейсхолдеров. Я даже цикл с трудом представляю себе в договоре, в моем понимании это тупо strtr(). Ну... Можно какой-нибудь mustache взять, скажем. Или xml+xslt, если и правда там нужна гибкость какая-то.
Всё действительно можно сделать плейсхолдерами. Почему-то не думал об этом. Я ими пользовался только в разрезе формирования запросов к бд. Спасибо, почитаю.
 
Сверху