2009-12-21 3 views
2

Скажем, существует страница, которая имеет много блоков, связанных с ней. И каждый блок нуждается в индивидуальном рендеринге, сохранении и данных.Модели моделирования джанго моделей

Проще всего, с кодовой точки зрения, определять разные классы (следовательно, модели) для каждой из этих моделей. Упрощенный следующим образом:

class Page(models.Model): 
    name = models.CharField(max_length=64) 

class Block(models.Model): 
    page = models.ForeignKey(Page) 

    class Meta(): 
     abstract = True 

class BlockType1(Block): 

    other_data = models.CharField(max_length=32) 

    def render(self): 
     """Some "stuff" here """ 
     pass 

class BlockType2(Block): 

    other_data2 = models.CharField(max_length=32) 

    def render(self): 
     """Some "other stuff" here """ 
     pass 

Но тогда,

  • Даже с этим кодом, я не могу сделать запрос как page.block_set.all() получить все различные блоки, независимо от типа блока.
  • Причина в том, что каждая модель определяет другую таблицу; Работая над этим, используя модель привязки и общие внешние ключи, можно решить проблему, но она по-прежнему оставляет несколько запросов таблиц базы данных на странице.

Что было бы правильным способом его моделировать? Можно ли каким-то образом использовать общие внешние ключи (или что-то еще), чтобы хранить данные предпочтительно в одной и той же таблице базы данных, но при этом получить парадигмы наследования.

Update:

Моя точка была, Как я все еще могу получить ООП парадигм работать. Используя тот же метод с , так много ifs не то, что я хотел сделать.

Лучшим решением, как мне кажется, является создание отдельного стандартного класса python (желательно в другой blocks.py), который определяет сохранение, которое сохраняет данные и их «тип», создавая экземпляр одной и той же модели. Затем создайте тег шаблона и фильтр, который вызывает методы рендеринга, сохранения и другие методы, основанные на типе модели.

ответ

4

Не моделируйте страницу в базе данных. Страницы представляют собой презентацию.

Первый - и прежде всего - получите данные в порядке.

«И каждый блок нуждается в индивидуальном рендеринге, сохранении и передаче данных». Разбейте это: у вас есть уникальные данные. Игнорировать «блок» и «рендеринг» с точки зрения модели. Просто определите данные вне зависимости от презентации.

Серьезно. Просто определите данные в модели без какого-либо рассмотрения представления или разглашения или чего-либо еще. Получите модель данных правильно.

Если вы путаете модель и презентацию, вы никогда не получите ничего, чтобы хорошо работать. И если вы его заработаете, вы никогда не сможете продлить или повторно использовать его.

Второй - только после того, как модель данных право - вы можете обратиться к презентации.

Ваши «блоки» могут быть выполнены с помощью HTML <div> тегов и таблицы стилей. Попробуй это первым. В конце концов, модель работает и очень проста. Это просто HTML и CSS, отдельно от модели.

Ваши «блоки» могут потребовать специальные теги шаблонов для создания более сложного условного HTML.Попробуй второй.

Ваши «блоки» могут - в крайнем случае - быть настолько сложными, что вам нужно написать специализированную функцию просмотра для преобразования нескольких объектов в HTML. Это очень, очень редко. Вы не должны этого делать, пока не убедитесь, что вы не можете сделать это с помощью тегов шаблонов.


Редактировать.

«запросов различных внешних источников данных»

«отдельные простые классы (не модели), которые имеют метод сохранения, которые пишут в одной таблице базы данных.»

У вас есть три совершенно разных, несвязанных друг друга вещей.

  • Модель. Постоянная модель. С помощью метода save(). Они делают очень, очень мало. У них есть атрибуты и несколько методов. Нет «запрос различных внешних источников данных». Нет «рендеринга в HTML».

  • Внешние источники данных. Это обычные классы Python, которые получают данные. Эти объекты (1) получают внешние данные и (2) создают объекты модели. И ничего больше. Нет «настойчивости». Нет «рендеринга в HTML».

  • Презентация. Это обычные шаблоны Django, которые представляют объекты Model. Нет внешнего запроса. Нет настойчивости.

+0

Point о Right модель данных взята, спасибо. В моем случае для разных типов блоков мне нужно запросить различные внешние источники данных и визуализировать их в совершенно другом html. Кроме того, кешируйте данные (на уровне блоков). Таким образом, теги блоков на самом деле не помогают. Я имею в виду только отдельные простые классы (не модели), которые имеют метод сохранения, которые записываются в ту же таблицу базы данных. –

1

Я только что закончил прототип системы, которая имеет эту проблему в пиках: базовый класс продукта и около 200 классов детализации, которые сильно различаются. Существует много ситуаций, когда мы делаем общие запросы к Продукту, но затем хотим иметь дело с деталями, относящимися к подклассам, во время рендеринга. Например. получить все продукты от Vendor X, но отображать несколько разных шаблонов для каждой группы из определенного подкласса.

Я добавил скрытые поля для GenericForeignKey в базовый класс и автоматически заполняет content_type & object_id класса ребенка на сохранение() время. Когда у нас есть общий объект Product, мы можем сказать obj = prod.detail, а затем работать непосредственно с объектом подкласса. Взял около 20 строк кода, и он отлично работает.

В ходе испытаний мы столкнулись с тем, что manage.py dumpdata, а затем manage.py loaddata продолжали бросать Integrity Errors. Оказывается, это хорошо известная проблема, и исправление ожидается в версии 1.2. Мы обходим это с помощью команд mysql для сброса/перезагрузки набора тестовых данных.

 Смежные вопросы

  • Нет связанных вопросов^_^