django 1.3 тег шаблона URL и представления на основе классов - PullRequest
1 голос
/ 21 февраля 2012

Я только начинаю переносить приложение, которое у меня есть, с 1.3 на 1.3.

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

Это единственный способ, которым я могу использовать тег шаблона URL с общим представлением на основе классов?
Обратный URL Django с параметрами для представления на основе классов
т.е. нужно назвать каждую запись URL?

Мне кажется нелепым, потому что одна из основных философий Джанго - СУХАЯ, и все же мы здесь ... КУДА ...

Заранее спасибо.

Edit:
Итак, у меня есть https://gist.github.com/1877374

и получите ошибку TemplateSyntaxError Поймано NoReverseMatch при рендеринге: обратное для 'views.HomeView.as_view' с аргументами '()' и ключевыми словами-аргументами '{}' не найдено.

Я использую это неправильно?


Tangent:
Я хотел бы объяснить немного больше о том, почему я считаю, что мы делаем RY-IN, если нам нужно назвать каждую запись в файле urls.py

мой urls.py обычно выглядит https://gist.github.com/1877462

Я полностью понимаю, что такое разъединение.
Дело в том, что у нас есть возможность сделать это , когда требуется . Я абсолютно использую функцию имени, когда мне нужно. В противном случае, зачем мне тратить время и силы на добавочное добавление URL-адреса к каждой записи и присваивать имена каждой записи, если часто они совпадают с именем класса / функции в views.py?

Может быть, это должно быть разветвлено в отдельный вопрос о SO.

Ответы [ 3 ]

2 голосов
/ 06 марта 2012

Вот довольно простое объяснение того, почему нельзя изменить представления на основе классов, не назвав их. Я не очень знаком с внутренностями Джанго, поэтому я счастлив, что меня поправили.

С функциональным представлением

# my_app.views.py
def my_view(request):
    return HttpResponse("Hello, world!")

вы можете изменить my_app.views.my_view, потому что это путь вызываемой функции просмотра.

С представлением на основе классов,

# my_app.views.py
class MyView(TemplateView):
    template_name = "hello_world.html"

вы не можете повернуть вспять my_app.views.MyView, потому что это не вызываемый объект просмотра. Вызываемое представление - MyView.as_view(). Если вы присвоили MyView.as_view() переменной в ваших представлениях следующим образом:

# my_app.views.py
class MyView(TemplateView):
    template_name = "hello_world.html"
my_view = MyView.as_view()

# urls.py
url('^$', `my_view`),

тогда вы сможете изменить my_view, не называя его. Этот параметр повторяет столько же, сколько и название вашего URL, поэтому я не думаю, что вам понравится!

Однако, когда вы вводите MyView.as_view() непосредственно в шаблон URL, это анонимная функция. Он не был назначен какой-либо переменной, поэтому нет пути, который вы можете использовать, чтобы изменить его. Точно так же вы не сможете изменить следующее:

url('^$', lambda request: HttpResponse("Hello, World!")), 

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

2 голосов
/ 21 февраля 2012

Во-первых, это не повторение. Где вы дважды называете URL? Это будет повторяться.

Во-вторых, именование шаблонов URL не требуется - , но дает много преимуществ - поэтому и рекомендуется. Он также предоставляет вам гибкость в изменении имен методов представления без необходимости изменения шаблонов. Вы можете выбрать набор имен URL и передать их своему дизайнеру для работы с шаблонами, и вы можете свободно называть методы (или классы) представления так, как вам нравится.

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

Или вы можете избежать большинства вышеперечисленных, назвав шаблоны URL.

1 голос
/ 21 февраля 2012

Я не вижу, как это нарушает принцип СУХОЙ - все они являются отдельными представлениями, которые делают разные вещи, и каждому из них присваивается уникальный идентификатор, чтобы не сталкиваться при обратном обращении. Во всяком случае, использование именованных URL-адресов уменьшит код, который вы должны писать на уровне шаблона, и сделает вашу схему URL более читабельной

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...