Комментарии 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
0
> Если форм несколько, то
выносим код в отдельный шаблон form.html, и {% include %} его по необходимости.
выносим код в отдельный шаблон form.html, и {% include %} его по необходимости.
+1
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 %}
+2
Верстальщики за это спасибо скажут. Самому приходится верстать проекты под джанго и формы вызывают особое недовольство. Очень неудобно, когда приходится дергать программиста, чтобы что-то изменить в форме.
+1
По моему осталось проманкипатчить кое что, чтоб этот метод стал доступным… Или каким образом вы передаёте именно этот сабкласс форме?
0
у меня например вот так
обратите внимание на последнею строчку
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
обратите внимание на последнею строчку
+1
Мне самым простым и прямым решением показалось просто наследоватьс вои формы не от forms.Form, а от своего класса. Кроме того, так решается задача централизованной раздачи css-классов.
0
Это конечно же хорошо, но как вы будете отображать формы из 3rd party библиотек? Всё равно манкипатчить придётся… Мне кажется лучше сразу так и поступить. И цсс классы можно точно так же проманкипатчить, ничего в этом плохого не вижу.
В любом случае, каждый пусть решает как ему удобней это сделать, я на своём мнении не настаиваю.
В любом случае, каждый пусть решает как ему удобней это сделать, я на своём мнении не настаиваю.
0
self.fields[field]
выглядит как-то плохо.for field in self.fields.values(): field.widget.attrs['class'] = 'some-class other-class'
+2
ну и говнокод…
-7
Вот так шаг за шагом вы и придете к Друпалу :)
>>as_p(), as_table() и as_ul()
а где as_div и as_fieldset ??? джангисты не знают, что значит перечислиый список и параграф, что эти методы там вообще делают?
>>as_p(), as_table() и as_ul()
а где as_div и as_fieldset ??? джангисты не знают, что значит перечислиый список и параграф, что эти методы там вообще делают?
-2
наиболее употребимое вынесено в отдельные методы, никто не мешает сделать и as_div, и as_fieldset, и руками нарисовать форму.
0
Неа, не придем) Добавили 3 метода 4 года назад назад, убирать потом не стали — есть они не просят, часто удобны, обратная совместимость. А новые очень вряд ли появятся, т.к. добавишь as_div — попросят as_fieldset и тд, и будет друпал. Когда внешний вид или возможность настройки не очень важны, можно использовать as_* — это быстро и просто, когда это важно — делать по-другому, это тоже не сложно, никто эти as_* не навязывает.
+1
сорри, предыдущий комент адресован не вам, а в главную ветку.
0
еще django-uni-form хвалят, сам не пробовал, правда
0
Для required-поля можно потом вставлять звездочку, например, так:
Ну это так, чтобы не переписывать шаблон.
$("form ul li.field-required label").append(' *');
Ну это так, чтобы не переписывать шаблон.
+1
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Оформляем формы