2
Я хочу, чтобы генерировать автоматизированные сообщения, связанные с конечным (> 20, < 100) количество типов:шаблонов Джанго в логике модели
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)
в то время как сообщение «STATUS» будет что-то вроде
"Hi, this is a reminder that you changed your %s status to %s." % (status_type, new_status)
Теперь, сложность здесь в том, что мы должны оказывать сообщение другому для разных типов. Вот моя попытка мозгового штурма несколько различных подходов:
- обновляют модели, чтобы иметь модель базы сообщений и производный по одному для каждого, со своим собственным типом конструктора, сохраняя «строковые шаблоны» внутри конструкторов для каждой модели , Это соответствует шаблону разделения моделей с разной логикой (и я обычно делаю это для модели разных «типов»), но чувствует себя неуклюжим, потому что помимо логики создания сообщений эти ребята в основном одинаковы. Единственное различие в логике происходит от создания самих сообщений, и кажется, что это расточительно расколоть только из-за этого.
- Сохраните модель как есть, создайте методы класса в коде, чтобы сделать завод для каждого типа, сохраняя «строковые шаблоны» внутри класса (или даже внутри базы данных). Это самый легкий, но он чувствует себя грязным.
- Это творческий/сумасшедший (отсюда и название): сохраните модель как есть и сохраните строковые шаблоны в качестве фактических файлов шаблонов. В конструкторах используйте библиотеку шаблонов Django для рендеринга этих файлов и возврата строк. Это кажется хорошим, потому что он отделяет жестко кодированные данные от кодовой логики, но он чувствует себя воинственным, поскольку я использую шаблоны на двух разных уровнях кода (один для создания моделей и один для представлений). Это «чувствует» неправильно, но я не могу точно определить, почему.
Так основные вопросы:
- Что является лучшей практики в этой ситуации? Это один из них или это какой-то другой подход?
- есть ли «пример модели» этой практики где-нибудь? Я чувствую, что многие системы генерируют автоматические оповещения/сообщения, поэтому, если у вас есть особенно хороший код, я бы хотел посмотреть на него.
Спасибо!
-yan
Глядя на ваши образцы сообщений, кажется, что метод post_save может быть хорошим моментом для его повышения. Как вы думаете?. Мое приложение также поднимает сообщения, а также я не знаю, где лучше всего поднять его, на просмотр или на post_save. Я следую вашему вопросу. – danihp
хорошо, если вопрос просто сделать это на вид или на post_save, я чувствую, что post_save строго лучше, чем представление, потому что эта ассоциация читаемого человеком сообщения к данным, используемым для генерации сообщения, является логикой на уровне модели и не должна быть зависящим от вида. Как вы думаете? – yanzhang
Я жду кого-то, кто ответит на ваш вопрос. На мой взгляд: в первый раз я написал эти правила в post_save, но было сложно проверить только условия, которые сообщение должно повысить, а затем переходить к представлениям. В это время я возвращаюсь к post_save. Я всегда предпочитаю писать коды и бизнес-правила для моделей. – danihp