Найти - Пользователи
Полная версия: Как сделать проверку в шаблоне?
Начало » Python для новичков » Как сделать проверку в шаблоне?
1 2
py.user.next
Попробуй использовать post.cat_id для различия категорий.

Сначала вставь такой код
 def post_detail(request, post_slug):
    post = get_object_or_404(Story, slug=post_slug)
    raise ValueError('x' + str(post.cat_id) + 'x')
    return None
А потом заходи в посты в разных категориях и смотри, какое число выводится в тексте исключения. Одинаковое это число или разные числа. Надо убедиться, что для разных категорий выводятся разные числа, а не одинаковые. И если выводятся разные числа для разных категорий, то надо убедиться, что для одной и той же категории число выводится одно и то же при разных обращениях к сайту.

Centner
Мне казалось что в Jinja можно как-то так-же.
Ну, в Jinja можно всё это делать и даже больше. Просто у тебя архитектура неправильная у всего проекта. Jinja'е нечего просто проверять, так как ты неразличимые топики сделал. У тебя фильм - это история, а история - это фильм. Чем они отличаются? Ничем они не отличаются. Вот сейчас нужно нарушать правило инкапсуляции из ООП и лезть во внутреннюю структуру этого топика, которая по правилу инкапсуляции из ООП должна быть неизвестна никому, кроме топика самого. Это вот к тебе подошёл бы человек и спросил тебя “как ты себя чувствуешь?”, ты бы сказал ему “хорошо” и всё. А в случае нарушения инкапсуляции он бы подошёл, разрезрал бы тебе грудь и стал бы сердце ощупывать, бьётся ли оно у тебя и правильный ли у него ритм, и потом даже зашил бы грудь обратно и реанимировал тебя. Ты был бы живой, но это неправильный способ определения здоровья и хорошего настроения, несмотря даже на то, что этот человек врач и знает, как это всё делать. Поэтому снаружи должно быть видно, что это, чтобы внутрь лезть не надо было. А у тебя этого нет. Поэтому ты теперь костыли пытаешься эти найти.
Centner
Проверил, категории разные конечно, и id разные.
Я конечно сделал проверку такого типа:
 {% if post.cat_id == 1 %}
Но это тоже получается хардкод.

Я понимаю о чем ты говоришь - буду переделывать.

За помощь спасибо.
py.user.next
Centner
категории разные конечно, и id разные
Они должны быть ещё константными. То есть они должны быть разными и они при разных запусках программы должны быть ещё и одними и теми же. Потому что они при разных запусках могут ставиться произвольно, и ты просто просто зашьёшь число какое-то в шаблон, а там будет потом другое число для этой же категории. При этом они все будут разные для разных категорий. Так что это тоже надо проверить.

Категорию ты можешь ещё передать снаружи в шаблон и придумать ей более фиксированный идентификатор, чтобы шаблон сделать яснее и защитить от всяких произвольных числовых значений. Ты можешь передать её в словаре, как я показывал передачу типа поста. То есть добавить в словарь ключ category_name и потом проверять его в шаблоне через
{% if category_name == 'story' %}
То есть так ты отвязываешься от чисел каких-то непонятных, чтобы человек читал и понимал шаблон сразу.

Ну, короче, читаемость кода - это тоже не простая вещь, не один день изучается. Это набор навыков, которые надо натренировывать часами. Сначала изучаешь теорию, читаешь книжки там разные (не одну, а несколько штук), читаешь много разных чужих кодов плохих и хороших, чтобы видеть разницу, а потом тренируешься в проектах писать читаемый код. Код должен быть таким, чтобы для него не требовались комментарии. Лучший комментарий - это пустой комментарий. Если у тебя код, который понятен без единого комментария, то это самодокументированный код. А это набор навыков, которые надо развивать. Из пустоты сами по себе они не появляются.
Centner
Спасибо большое.

py.user.next
Они должны быть ещё константными. То есть они должны быть разными и они при разных запусках программы должны быть ещё и одними и теми же. Потому что они при разных запусках могут ставиться произвольно, и ты просто просто зашьёшь число какое-то в шаблон, а там будет потом другое число для этой же категории. При этом они все будут разные для разных категорий. Так что это тоже надо проверить.

Но ведь используется БД, id присваивается автоматически и не меняется при каждом обращении.

Или речь о том что если кто-то другой будет заполнять БД, он может в другой последовательности заполнить категории и код работать не будет?
Тогда мне кажется проще будет добавить какой-нибудь параметр type и сделать его обязательным.
Либо сделать не одну таблицу а три.
py.user.next
Centner
Но ведь используется БД, id присваивается автоматически и не меняется при каждом обращении.
Centner
Или речь о том что если кто-то другой будет заполнять БД, он может в другой последовательности заполнить категории и код работать не будет?
Там используется не БД, а ORM, СУБД, БД и таблицы в этой БД. Как ORM может поменяться, так и СУБД может поменяться, так и БД может поменяться, так и таблицы в этой БД могут поменяться. И при каждом из этих изменений могут поменяться идентификаторы. Поэтому если эти идентификаторы напрямую будут проходить в шаблон Jinja, то при их изменении такой шаблон сломается, потому что числа будут не те в шаблоне стоять. И когда у тебя десять тысяч шаблонов таких, то они сломаются все. Хорошо ещё, если они тебе напишут, что они сломались, а могут вообще начать тихо показывать всякую ложную хрень. Поэтому мы шаблоны отвязываем от этих чисел, а сами эти числа сводим в одну точку, где при любых изменениях идентификаторов мы эти числа в этой одной точке все переписываем один раз и всё (скриптом).

Ну, например, тебе хостинг рубанут, скажут “через неделю с такого-то числа наш хостинг становится дороже на $500”, ты начинаешь переезжать, а на другом хостинге эту ORM не поставишь, например, или там ту же СУБД не поставишь. Тебе придётся переносить и переводить в другой вид. Так вот сайт переедет неизменным, а часть, которая к БД относится, полностью поменяется во всех своих частях. Вот эта хрень вся может вызвать проблемы. Поэтому мы заранее закладываем в шаблоны то, что никакие проблемы на них не повлияют. Удаляем связь между шаблонами Jinja'ы и идентификаторами в таблицах, находящихся в глубине базы данных. Шаблоны становятся независимыми от таблиц.

Вот просто представь. У тебя почка и сердце никак не связаны. Если почка отвалилась, перестала работать, то сердце всё равно продолжает биться. Поэтому почку можно удалить, вторая почка останется. И ты выживешь. А вот если бы они были связаны. Как бы и то про кровь, и это про кровь, должна быть типа связь между ними, они же про кровь. И в итоге у тебя почка отвалилась и сердце остановилось из-за этого. Тебе нужен был один врач нефролог, а тут тебе стало нужно два врача сразу нефролог и кардиолог и оба хирургами должны быть ещё. Ну и что? Ну и всё. Нефролог на месте, а кардиолог в отпуске и уехал куда-то неделю назад. А зачем было их связывать?
Centner
Вообщем, решил по твоему совету, начать другой проект, более сложный, но с правильным подходом, изначально.

Бьюсь над выводом форм. Стандартный вывод не подходит по верстке.
У меня вывод идет почему то двумя циклами, и v.value ничего не выводит.
 {% for field in rate %}
            {% for v in field %}
                <input name="rating" id="{{ v.id_for_label }}" value="{{ v.value }}">
                <label for="{{ v.id_for_label }}"></label>
            {% endfor %}
        {% endfor %}

Это форма для рейтинга через radioselect:
 class RateForm(forms.ModelForm):
    rating = forms.CharField(widget=forms.RadioSelect(choices=TYPE_SELECT))
    class Meta:
        model = Rating
        fields = ("rating",)
        labels = {
            'rating': '',
        }
py.user.next
Centner
Вообщем, решил по твоему совету, начать другой проект, более сложный
Да тебе надо на простых потренироваться сначала. Поделай простые проекты, вдруг ты их тоже не сможешь сделать. Главное, своё вот это теоретическое мнение о себе (о своих способностях) проверить на практике. Если теория и практика сходятся, то можно продолжать тренироваться на этом уровне для закрепления и прочистки навыков и потихоньку повышать уровень. А если же ты теоретически думаешь о себе, что ты мастер, а на практике оказывается, что ты не можешь смастерить то, в чём был уверен до этой практики, то тебе надо снизить планку для начала, откатиться на уровень ниже. Всё равно никто не будет тебя считать умным, если ты будешь типа умные программы писать, которые работают только понарошку или наполовину или на три четверти. Никто.

Вот сейчас в Альфа-Банке такие дураки работают. Ребята пишут основной софт там, который вот работал-работал, а потом раз и однажды мужику восемьдесят миллионов рублей долга начислил, потому что тот просто скопировал счета (link). Всё это может выглядеть умно и красиво, а в итоге банк такой классный так обосрался на всю страну. И то, что эти ребята код такой классный и умный писали, никто не будет говорить. Все будут говорить только, что в Альфа-Банке код полные дебилы пишут. Просто из-за одного такого раза.

Centner
У меня вывод идет почему то двумя циклами, и v.value ничего не выводит.
Тут я наблюдаю какие-то усложнения в шаблоне. А в шаблоне не должно быть вообще ничего сложного. Скорее всего, ты просто ответственность кода на питоне возложил на код на языке шаблонизатора. То есть то, что ты должен был проделать в коде, который работает до шаблона ещё, перенёс в шаблон и теперь даже отладить это не можешь.

1. Так что для начала подай в шаблон правильные данные (будто они были вычислены как-то там, сам сформируй их вручную).
2. Убедись, что эти данные через шаблон правильно выводятся в конечной странице.
3. Сделай в коде часть, которая уже вычисляет данные правильно и просто подаёт их в шаблон на той точке передачи, которую ты отладил в пункте 2.

Centner
Это форма для рейтинга через radioselect:
Да похрен. Так ты искать будешь этот баг то здесь, то там, а он может быть вообще где-нибудь в скрытом неожиданном месте, в рояле, например. Так что займись отладкой пошаговой на промежуточных тестовых данных, которые якобы вычислены были.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Powered by DjangoBB