Comments 25
Вещь простая, но все равно спасибо!
Поправьте ссылку, пожалуйста: docs.djangoproject.com/en/dev/topics/forms/index/#customizing-the-form-template
Поправьте ссылку, пожалуйста: docs.djangoproject.com/en/dev/topics/forms/index/#customizing-the-form-template
> Если форм несколько, то
выносим код в отдельный шаблон form.html, и {% include %} его по необходимости.
выносим код в отдельный шаблон form.html, и {% include %} его по необходимости.
form.html
other_template.html
{{ form.non_field_errors }}
{% for field in form %}
<div class="f_row">
{{ field.errors }}
{{ field.label_tag }}
<div class="f_input">
{{ field }}
{% if field.help_text %}<div class="note">{{ field.help_text }}</div>{% endif %}
</div>
</div>
{% endfor %}
other_template.html
{% with add_post_form as form %}{% include 'form.html' %}{% endwith %}
Верстальщики за это спасибо скажут. Самому приходится верстать проекты под джанго и формы вызывают особое недовольство. Очень неудобно, когда приходится дергать программиста, чтобы что-то изменить в форме.
По моему осталось проманкипатчить кое что, чтоб этот метод стал доступным… Или каким образом вы передаёте именно этот сабкласс форме?
у меня например вот так
обратите внимание на последнею строчку
def as_div(self):
return self._html_output(
normal_row = u'<div class="js-active forms__width %(html_class_attr)s" >\
<div class="forms__i">\
%(label)s %(field)s\
</div>\
%(help_text)s\
<div class="forms__hint">%(errors)s</div></div>',
error_row = u'%s',
row_ender = u'',
help_text_html = u'<div class="forms__hint">%s</div>',
errors_on_separate_row = False
)
forms.BaseForm.as_div = as_div
обратите внимание на последнею строчку
Мне самым простым и прямым решением показалось просто наследоватьс вои формы не от forms.Form, а от своего класса. Кроме того, так решается задача централизованной раздачи css-классов.
Это конечно же хорошо, но как вы будете отображать формы из 3rd party библиотек? Всё равно манкипатчить придётся… Мне кажется лучше сразу так и поступить. И цсс классы можно точно так же проманкипатчить, ничего в этом плохого не вижу.
В любом случае, каждый пусть решает как ему удобней это сделать, я на своём мнении не настаиваю.
В любом случае, каждый пусть решает как ему удобней это сделать, я на своём мнении не настаиваю.
self.fields[field] выглядит как-то плохо.
for field in self.fields.values():
field.widget.attrs['class'] = 'some-class other-class'
ну и говнокод…
Вот так шаг за шагом вы и придете к Друпалу :)
>>as_p(), as_table() и as_ul()
а где as_div и as_fieldset ??? джангисты не знают, что значит перечислиый список и параграф, что эти методы там вообще делают?
>>as_p(), as_table() и as_ul()
а где as_div и as_fieldset ??? джангисты не знают, что значит перечислиый список и параграф, что эти методы там вообще делают?
наиболее употребимое вынесено в отдельные методы, никто не мешает сделать и as_div, и as_fieldset, и руками нарисовать форму.
Неа, не придем) Добавили 3 метода 4 года назад назад, убирать потом не стали — есть они не просят, часто удобны, обратная совместимость. А новые очень вряд ли появятся, т.к. добавишь as_div — попросят as_fieldset и тд, и будет друпал. Когда внешний вид или возможность настройки не очень важны, можно использовать as_* — это быстро и просто, когда это важно — делать по-другому, это тоже не сложно, никто эти as_* не навязывает.
сорри, предыдущий комент адресован не вам, а в главную ветку.
еще django-uni-form хвалят, сам не пробовал, правда
Для required-поля можно потом вставлять звездочку, например, так:
Ну это так, чтобы не переписывать шаблон.
$("form ul li.field-required label").append(' *');
Ну это так, чтобы не переписывать шаблон.
Sign up to leave a comment.
Оформляем формы