Джанго шаблоны в модельной логике

Question

Я хочу создавать автоматические сообщения, которые связаны с конечным (> 20, <100) числом типов: </p>

class Message(models.Model):
    MSG_CHOICES = (
        ('MEETING', 'Meeting Reminder'),
        ('STATUS', 'Status Change Reminder'),
        ...
        )
    message = models.CharField(max_length=100)
    msg_type = models.CharField(max_length=10, choices=MSG_CHOICES)

Фактическое сообщение каждого будет зависеть от типа и аргументов, которые я должен передатьэто в какой-то момент.Например, сообщение «ВСТРЕЧА» в основном будет иметь вид:

"Hi, you have a meeting at %s with %s." % (time, person_to_meet)

, а сообщение «СОСТОЯНИЕ» будет выглядеть примерно так:

"Hi, this is a reminder that you changed your %s status to %s." % (status_type, new_status)

Теперь сложность заключается в том, что мы должнывизуализировать сообщение по-разному для разных типов.Вот моя попытка мозгового штурма нескольких различных подходов:

1. обновить модель, чтобы иметь базовую модель сообщений и производную для каждого, с собственным типом конструктора, сохраняя «строковые шаблоны» внутри конструкторовдля каждой модели.Это соответствует шаблону разделения моделей с разной логикой (и я обычно делаю это для моделей разных «типов»), но кажется неуклюжим, потому что, кроме логики создания сообщений, эти парни в основном одинаковы.Единственное различие в логике заключается в создании самих сообщений, и кажется, что разбивать их просто из-за этого.
2. Сохранить модель как есть, создать методы класса в коде, чтобы создать фабрику для каждого типа.сохраняя «строковые шаблоны» внутри класса (или даже внутри базы данных).Это самое простое, но кажется грязным.
3. Это творческий / сумасшедший (отсюда и название): оставьте модель как есть, и сохраните строковые шаблоны как фактические файлы шаблонов.В конструкторах используйте библиотеку шаблонов Django для визуализации этих файлов и возврата строк.Это кажется хорошим, потому что он отделяет жестко запрограммированные данные от логики кода, но это кажется странным, поскольку я использую шаблоны на двух разных уровнях кода (один для создания моделей и один для представлений).Это «неправильно», но я не могу точно определить, почему.

Итак, основные вопросы:

1. Какова наилучшая практика для этой ситуации?Это один из них или какой-то другой подход?
2. Есть ли где-нибудь "модельный" пример этой практики?Я чувствую, что многие системы генерируют автоматические оповещения / сообщения, поэтому, если у кого-то есть особенно хороший код, я бы хотел посмотреть его.

Спасибо!

-Янь

Answer 1

ИМХО, вам вообще не следует хранить сообщение в БД. Вы сохраняете msg_type. Этого должно быть достаточно. Ваша логика для отображения информации пользователю (через шаблон) должна справиться с этим. Это позволит вам локализовать сообщение, если вам потребуется в какой-то момент в будущем, на основе заголовка Accept-Language. По моему опыту, это плохая идея хранить пользовательские сообщения в БД. И, по крайней мере, на мой взгляд, это не совсем настоящая бизнес-логика. Кажется, он принадлежит слою пользовательского интерфейса. Хорошо. Просто мое мнение об этом. Этот вопрос довольно старый. Мне было бы интересно прочитать, что вы в конечном итоге сделали здесь.