Pull to refresh

Comments 14

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

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

Это так, просто размышления и крик души.

C Django Fluent Pages и Django Fluent Contents у самого сложились очень сложные взаимоотношения, и всё же я плачу, колюсь, но кушаю кактус. В итоге не пойму, то ли так всё хорошо, что я продолжаю использовать, то ли так всё плохо, что плачу.

Статья изложена не совсем человекопонятно, поэтому есть вопросы по стилю и по существу.
1)

модель, которая хранит в себе обычные страницы, а не отдельные записи в базе данных
Почему содержимое "обычной страницы" не может быть "записью в базе данных"? -)

2) Непонятно, в чём изначально была проблема.


если этот администратор начнёт добавлять новые записи в бд, то вёрстка поедет
Почему вёрстка будет разъезжаться, если добавляемый HTML-код всегда будет выводиться в заранее заготовленном для этого блоке шаблона, каждая страница — по своему псевдониму в URL?

3) Зачем нужно было использовать именно связку flatpages с sites framework и с ещё одной кастомной моделью? Тем более, что flatpages изначально задуман для plain-text содержимого, о чём говорит само название. К тому же sites framework нет смысла использовать, а) если сайт у вас только один или б) если содержимое разных сайтов хранится в одной БД с одним файловым инстансом проекта.

4) Наконец, зачем использовать для текстового содержимого
RichTextUpliadingField, если это поле для загрузки файлов, а не для заполнения контентом?

Я для подобной задачи просто создавал кастомную модель Article со служебными полями для названия (CharField), псевдонима страницы (SlugField), метатегов description и keywords (CharField) и самого HTML-содержимого (RichTextField из готового расширения django-ckeditor). Страницы редактировались в соотв. разделе админ-панели. Необходимости использовать sites framework со всем зависящим и от него дополнениями не было.
На некоторые из ваших вопросов у меня есть ответы в текcте, а на которые есть в офф. документации (на часть ваших вопросов сразу может ответить документация). Надеюсь следующее сообщение поможет вам разобраться)
  1. По поводу первого пункта(возможно не совсем корректно расписал, но так мне казалось будет понятнее для новичков), да у flatpages тоже будет отдельная запись в бд, но сразу со всеми данными, и самое главное, это то что не будет возможности на одну страницу добавить ещё данных из моделей (если создадим новый записи в базе данных, то наш шаблон в цикле их выведет на страницу, отсюда вёрстке ‘кирдык’, может так понятнее), как это делается в ListView, TemplateView.
  2. Если вы знакомы, например, с ListView, то любая запись, добавленная админом, через цикл фор будет добавлена на страницу. Пример кода: ({% for object in object_list %}). В самом начале я написал, что данное поведение можно изменить, сделав, например, в get_queryset выборку лишь первой записи из бд, то же самое и с TemplateView(но в другом методе). Но это плохой тон, и я считаю делать так абсолютное неправильно. Опять же в предисловии более грамотно описано почему.
  3. Без 'django.contrib.sites' flatpages не будет работать. См. документацию, см. мой пост, там я объяснил почему. У вас будет просто ошибка. Я усовершенствовал работу flatpages сделав нужную и полезную вещь для работы с простыми страницами, которые требует редактора контента для многих вот таких задач. “Cms в нано размере”. Ни где не написано, что расширять стандартный функционал джанги нельзя. Мне дали инструмент, я его улучшил) По-другому сделать никак нельзя, что бы одна модель (одна запись в бд) соответствовала одной странице. Лепить свой велосипед с нуля ещё хуже, а вот базовые классы не позволят этого сделать никак, только используя костыли в виде выборки из бд)
  4. 4По поводу этого пункта, для полной работы со всеми прелестями этого редактора, было выбрано именно это поле. Возможно понадобится загрузка файлов в будущем для админа. Это уже больше архитектурное замечание (оптимизация базы данных, скорости и тд), нежели замечание работоспособности. Тут уже кто как хочет, так и делает, поэтому я изначально отсылал людей самим установить ckeditor.

Надеюсь я помог) Если у вас есть более лаконичное решение моей поставленной задачи, буду рад почитать на хабре:)
По-другому сделать никак нельзя, чтобы одна запись в бд соответствовала одной странице… базовые классы не позволят этого сделать никак
Можно взглянуть на это с другой стороны. Я легко решал подобную задачу обычным функциональным view. В модели Article одна запись — одна страница. Поле slug — уникальный псевдоним, по нахождению которого в URL в шаблоне рендерится именно эта конкретная страница. URL таких страниц не должны конфликтовать с другими URL проекта. Вот похожий пример на Тостере.

Если очень хочется всегда использовать class-based views — как можно отобразить одну страницу с помощью, скажем, DetailView, написано на Хабре и на SO.
Отвечу по поводу DetailView, дабы не за блуждать людей, для этого базового класса нужно обязательно передавать pk в url, по которому будет искаться запись в базе данных(по этому я даже и не упоминал об этом классе в статье). По этому нет, такой способ не пройдёт, у вас будет ошибка. Ибо данный класс ждёт регулярку, в которой обрабатывается pk(ключ) и данный класс получает его с гет запросом, по которому ищет в дальнейшем запись. ( как пример из моего проекта — url(r'^blog/(?P\d+)$',..). А вот реализовать данный функционал, например, с помощью функции обработчика + те модули, которые написаны комментарием выше, это как раз можно, думаю, это как ещё одно элегантное решение, пока не испытывал, но можно, проблем не будет). Но в таком случае это лишь решение одной задачи. Тут же, я ещё упор делал на то, что админ может создавать сколько угодно страниц сам с различным контентом, а применение этому может быть широкое, вплоть до написания сайтов исключительно использующих данный функционал( такие сайты кстати есть, когда решал эту задачу, натыкался на статьи, где описывали крупные сайты, работающие исключительно на flatpages)
Насчёт вашего решения, в принципе да, можно так, неплохой совет, тоже как вариант)
Я тут подумал, хотя если переопределить в DetailView атрибут slug_field методы get, get_queryset и обработать сложную регулярку из запроса(написанную в urls.py), и сделать её как pk, а в ней будет происходить обработка как раз всех адресов, то у нас может быть и получится вывести нужную страницу записав в одном из полей бд, поле, которое и будет отвечать за url адрес страницы, тем самым сделав одну запись. Но это я уже сам сейчас на ходу придумал) по этому наверняка не скажу реализацию, но попробовать потом можно) Я об это думал, когда разрабатывал данный метод и это тогда в голову не пришло тогда) А сейчас неожиданно пришёл в голову такой способ) Если вы что-то подобное имели введу, то расписали бы, так понятнее было бы, а так данный пост это пока что мои логические рассуждения, может кому-то поможет в дальнейшем такой вариант, который я сейчас предложил)
Насколько я вижу в примере из актуальной документации к Django 1.11, DetailView вполне может работать с псевдонимом из URL без обязательного первичного ключа.
Соответственно из URL может браться либо какое-то одно уникальное поле, однозначно идентифицирующее запись наряду с pk (например, псевдоним), либо комбинация полей, однозначно идентифицирующая запись в составе уникального ключа (например, дата/время/псевдоним).
другим Возможно, в прошлых версиях было по-другому.
В частности, так и есть, но есть нюансы в реализации и в понимание. Советую тоже поработать с классами. Хотелось бы уточнить, я под pk имел введу, именно параметр — идентификатор. Это могут быть разные поля (соответственно разные регулярки), заданные либо pk_url_kwarg = 'pk', как первичный ключ, а в дальнейшем его можно преобразовать и изменить стандартную реализацию сортировки по бд(перехватить в методе ключ и изменить сортировку по любому полю), либо можно реализовать, так как вы предположили в теории, это реализуется с помощью slug_field(строка с именем поля модели, в котором хранится запись) + slug_url_kward. Забыл про эти атрибуты, посмотрел у себя в записях. Действительно реализовывать данную задачу можно по-разному. Но регулярка должна быть обязательно, которая передает значение, полученное из url адреса, в метод get. Ключ, по которому будет фильтроваться база данных в соответствие с параметром, должен быть. Сделать его можно разным (например, изменить работу pk, либо как написано выше) и задать по-разному, соответственно будет разная сложность. Но это все возможные варианты, больше нет. Я лично давно работаю с классами, всегда интересно практиковаться в них, функции уже давно не использую, считаю плохой практикой, и реализовывал сложные структуры с get, get_queryset, get_context_data, post.
. Но в данном рассуждение, действительно лично даже я для себя смог выявить и придумать много решений, которые потом попробую, но это уже на отдельную статью клонит, детальный разбор реализации DetailView и нюансы в работе. Надеюсь вам и читателям понравятся ещё вот такие способы, который я сейчас придумал и надеюсь я их не слишком сложно расписал, и они понятные. Так что можно либо моим способом, которые я написал в комментарии выше, либо способом с slug_field + slug_url_kward. Думаю, эти варианты сработают, всё же я не тестировал пока, но думаю сработают. Конечно более глубокое описание, тестирование и выводы, это уже полноценная статья, которая пишется не быстро, с редактированием и вычитыванием.
Опят же то что вы написали не совсем корректно, работать можно не только через pk, но и через другие ключи(имя параметра, в котором передаётся интернет-адрес — в slug_url_kwarg, например), которые будут опираться на нужные поля в базе данных, нужное поле в бд, пишется в другом атрибуте. Так будет корректнее.
работать можно не только через pk, но и через другие ключи
Об этом, собственно, я и говорил.-)
Only those users with full accounts are able to leave comments. Log in, please.