Общий подход к созданию сайта Трясогузки на основе существующей базы данных

Question

Пожалуйста, предложите руководство по настройке сайта трясогузки из существующей, довольно большой базы данных.

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

Допустим, я работаю с базой данных живых существ. В этом сценарии каждая запись в основной таблице базы данных соответствует определенному виду.

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

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

Как лучше всего импортировать базу данных и получить доступ к данным в трясогузке? Я мог бы:

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

   - или же -

2. импортировать данные в базу данных сайта Трясогузки, независимо от структуры страницы. Затем мне пришлось бы создавать модели фрагментов для доступа к данным и добавлять код для динамического отображения страницы для любого выбранного вида на основе данных, предоставленных соответствующим запросом, выполненным для этих фрагментов.

Я полный новичок во всем этом, но метод 1 может иметь два преимущества: предопределенные страницы, созданные во время импорта, уже будут иметь слаги, которые я могу легко преобразовать в интерактивные ссылки на страницах индекса; и предопределенные страницы будут доступны поисковым системам.

Метод 2 кажется мне более чистым — хранение ядра, «данных данных» отдельно от «данных страницы» (таких как заголовок и ярлык) логично и упростило бы процедуры импорта/экспорта. Но правильно ли я понимаю, что это уменьшит видимость отдельных страниц для поисковых систем? Помимо программирования, необходимого для динамического рендеринга страниц, есть ли у него другие преимущества или недостатки по сравнению с методом 1?

(Что касается метода 2: в трясогузке, как страницы могут отображаться динамически из результатов запроса на основе фрагментов? Я знаю о RoutablePageMixin, но примеры, которые я нашел, используют его для доступа к уже определенным страницам трясогузки. Вместо этого я хотел бы поместить данные из сниппетных запросов в шаблон с слагом, созданным в процессе рендеринга страницы. Буду признателен за рецепт или пример.)

Answer 1

Пока никто не ответил на этот вопрос, но я получил очень полезные рекомендации от опытного разработчика трясогузки, с которым связался сам. Основываясь на этих данных, я решил использовать метод № 1 (страница с трясогузками для каждого отдельного предмета/вида) по причинам, которые я изложу в конце этого поста.

Во-первых, вот отредактированная версия ввода, который я получил через пару электронных писем:

Я не могу дать вам определенного ответа, так как недостаточно знаю проблему, которую вы пытаетесь решить, и помните, что в будущем все можно изменить. Но я думаю, что изначально было бы проще выбрать вариант 1. Подход «страница как сущность» упрощает рассмотрение всего этого. Вот некоторые плюсы и минусы, которые следует учитывать:

1. Базовые модели страниц

• Преимущества: вы получаете слаги, уникальные URL-адреса для каждой сущности, функции SEO, элементы управления рендерингом страницы (например, флажок публикации), поиск, перевод и т. д. — все эти функции работают из коробки без особых усилий. Вы получаете древовидные структуры бесплатно.
• Недостаток: на раннем этапе разработки вы вынуждены использовать иерархию URL и страниц, что может не подойти в будущем. С тысячами страниц вы можете начать сталкиваться с некоторыми проблемами производительности, а редактирование данных страницы с помощью административного интерфейса трясогузки не очень эффективно. Будет непросто обмениваться страницами на нескольких сайтах (например, если у вас есть упрощенный сайт для общего пользования, другой сайт с большим количеством данных, где требуется вход в систему.
  • Смягчение недостатков:
    Структура URL -адресов — настройте иерархию страниц, независимую от ваших категорий/группировок (см. ниже).
    Производительность — пользовательский код может помочь, если вы начнете сталкиваться с проблемами, но лучше подождать, пока у вас действительно не возникнут проблемы. Список страниц хорошо кэшируется и не обращается к более глубоким моделям, пока они не понадобятся.
    Интерфейс редактирования — настройка редактирования может быть улучшена с помощью ModelAdmin, чтобы предоставить вам несколько способов доступа/навигации
    по спискам страниц —https://docs.wagtail.io/en/stable/reference/contrib/modeladmin/index.html
    Межсайтовое совместное использование — не очень простой способ решить эту проблему.

2. Модель Core Entity в виде простых моделей Django (используется с миксином Snippets)

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

   • Положительные стороны: больше контроля над тем, как используются модели сущностей, нет необходимости придерживаться некоторых жестких полей Title/Slug/id и т. д., больше контроля над тем, как интерфейс редактирования представляет эти сущности (например, с помощью редактирования сниппета или ModelAdmin без чтобы подумать о том, как эти элементы используются в области пользовательского интерфейса редактирования страницы).
   • Недостатки: потенциальные проблемы с производительностью для отображения списков фрагментов в выборе, интернационализация/перевод будут сложнее, когда вы доберетесь до этого момента, отображение каждого объекта как отдельной страницы сложнее и потребует небольшого переписывания некоторых вещей, которые делают модели страниц. уже.
   • Смягчение недостатков:
     Производительность - аналогично предыдущему, решите ее, когда она станет проблемой, вам может понадобиться запачкать руки с помощью более умного индексирования и кэширования запросов Django.
     Интернационализация - возможна, но вы можете обнаружить, что вам придется немного работать против фреймворка.
     Автономный рендеринг страницы - routablePageMixin - ваш друг, вам нужно будет по существу реализовать просмотр страницы, который работает для каждой уникальной сущности, генерируя слаги на лету (которые, как вы помните, могут измениться, что означает последствия для SEO) и другие вещи, которые делают обычные просмотры страниц. хотя по умолчанию все выполнимо.

В любом случае важно тщательно спланировать структуру страницы. Для первого варианта было бы намного лучше использовать более плоский подход, даже несмотря на то, что древовидная структура страниц позволяет легко сделать вещи действительно вложенными — иногда это может иметь неприятные последствия. Если структура вашей страницы имеет плоский подход к сущностям (т. е. одна страница для «сущностей», и каждая сущность представляет собой отдельную страницу непосредственно под ней), то вы можете создавать другие страницы или другие фрагменты, теги или сочетание всего, что связано на эти страницы сущностей. Затем вы можете сделать 100 способов «списка» этих страниц, которые полностью отделены от фактической отдельной страницы объекта (с точки зрения древовидной структуры).

Имея в виду вышеизложенное, я решил, что преимущества связывания наших основных данных со структурой страницы трясогузки перевешивают преимущества хранения данных в независимых моделях/таблицах. Одним из важных факторов является просто то, что все пойдет быстрее, когда я просто пытаюсь запустить первую версию сайта. Другое дело, что переведенные/интернационализированные версии сайта действительно запланированы, поэтому я хочу воспользоваться преимуществами поддержки Трясогузки в этой области.

Что касается неэффективности редактирования больших объемов данных в трясогузке, решение состоит в том, чтобы использовать инструменты базы данных, а затем загружать изменения в базу данных трясогузки. Доступ к этим основным полям контента, вероятно, придется ограничить в администраторе трясогузки, чтобы редакторы контента не вносили изменения, которые будут перезаписаны при следующей загрузке.

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

с открытым исходным кодом, который использует конфигурацию в стиле фрагмента для своих основных данных : https://github.com/okfn/rtei/https://www.rtei.org/en/Но с тех пор я наткнулся на впечатляющий проект Wagtail