<table>{{ form }}</table> vs {{ form }}

[guettli]

I am unsure how to render a form.

I see these ways

• <table>{{ form }}</table> 
  
• {{ form }}

If I use a model form, then the first way is the correct one.

How to you solve this?

[Todor Velichkov]

Take a look at:
1) Form rendering options
2) Outputting forms as HTML

{{ form }} and {{ form.as_table }} are basically the same.
So in terms of valid markup <table>{{ form }}</table> would be more correct.

[guettli]

Am Donnerstag, 4. Mai 2017 16:03:25 UTC+2 schrieb Todor Velichkov:

Take a look at:
1) Form rendering options
2) Outputting forms as HTML

{{ form }} and {{ form.as_table }} are basically the same.
So in terms of valid markup <table>{{ form }}</table> would be more correct.

OK,  <table>{{ form }}</table> is what I do now. Somehow I am unsure if this is really the best way.

But I will do this for until I find a better solution.

Thank you Todor for your answer.

[Melvyn Sopacua]

On Friday 05 May 2017 06:17:12 guettli wrote:

> Am Donnerstag, 4. Mai 2017 16:03:25 UTC+2 schrieb Todor Velichkov:

> > Take a look at:

> > 1) Form rendering options

> > <https://docs.djangoproject.com/en/1.11/topics/forms/#form-rendering

> > -options> 2) Outputting forms as HTML

> > <https://docs.djangoproject.com/en/1.11/ref/forms/api/#outputting-fo

> > rms-as-html>

> >

> > {{ form }} and {{ form.as_table }} are basically the same.

> > So in terms of valid markup <table>{{ form }}</table> would be more

> > correct.

>

> OK, <table>{{ form }}</table> is what I do now. Somehow I am unsure

> if this is really the best way.

 

There is never a best way. Only a best way for the job.

Django's job is to provide sensible, workable defaults. Table, paragraph and list view are 3 common ways to render form elements.

 

If you however use Bootstrap for css, you're much more helped by using the bootstrap3 package. Example:

 

<form method="POST">

{% csrf_token %}

{% bootstrap_form form %}

{% buttons submit='Go!' %}{% endbuttons%}

</form>

 

--

Melvyn Sopacua

[Jani Tiainen]

And, if your really want to, you can do all that manually without using django rendering facilities - since nothing forces you to do that. It's just few convenience tools to create something to start with.

That way you have full control over your forms and how they look like and where are all the fields placed.

And to use bootstrap you don't need any special package, you can do it without it just fine.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9008764.HJ6FAVUOio%40devstation.
For more options, visit https://groups.google.com/d/optout.

-- 
Jani Tiainen

[Melvyn Sopacua]

On Tuesday 09 May 2017 14:08:44 Jani Tiainen wrote:

 

> And to use bootstrap you don't need any special package, you can do it

> without it just fine.

 

To render a webpage, you don't need Django you can do just fine typing HTML. What's your point really?

 

--

Melvyn Sopacua

[guettli]

I know that I can render a webpage without django.

What is the point?

I don't want to do the same thing over and over again.

I search simple, easy and small solutions based on solid basic facts.

This is a basic fact, and AFAIK this basic question is not solved yet.

<table>{{ form }}</table>    vs    {{ form }}

The answer "do what fits" is not an answer for me. I don't want to waste mental energy and
think about this over and over again.

I know that real super heroes prefer the hard way. I don't like the hard way. Call me wuss, pussy, weenie if you want to.

[Jani Tiainen]

Hi,

"rightway" to do things is to keep rendering (html) in the place where it belongs to - in templates. That's the main functionality of templates.

Unfortunately traditionally Django forms have been doing things wrong and pushed HTML rendering to Python code - bascially to change your HTML you need to change Python code, which in production would mean deploying site again.

django-sniplates [1] is one of such library that pushes rendering solution to templates. Another alternative is

Fortunately Django 1.11 got template based widget rendering [2]. Which is the right direction.

But it's really up to you which way you choose.

[1] https://sniplates.readthedocs.io/en/latest/

[2] https://docs.djangoproject.com/en/1.11/ref/forms/renderers/

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/aa114307-d17a-4c6e-b32e-d2533bac5890%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

-- 
Jani Tiainen

[knbk]

On Tuesday, May 16, 2017 at 9:51:07 AM UTC+2, guettli wrote:

This is a basic fact, and AFAIK this basic question is not solved yet.

<table>{{ form }}</table>    vs    {{ form }}

That question is actually answered by the documentation:

• For flexibility, the output does not include the <table> and </table> tags, nor does it include the <form> and </form> tags or an <input type="submit"> tag. It’s your job to do that.

 

[Russell Keith-Magee]

On 16 May 2017, 12:51 AM -0700, guettli <guettli...@thomas-guettler.de>, wrote:

I know that real super heroes prefer the hard way. I don't like the hard way. Call me wuss, pussy, weenie if you want to. 

That kind of language is completely unnecessary. I don’t care how frustrated you are - the Django community code of conduct requires that you keep a civil tone. If you persist in using language like this, we’ll block your account from posting.

Yours,

Russ Magee %-)

[guettli]

Hi Russell Keith-Magee,

which version do you use? With <table> or without table?

   <table>{{ form }}</table> vs {{ form }}

Regards,
  Thomas

[Melvyn Sopacua]

On Tuesday 16 May 2017 00:51:07 guettli wrote:

> Am Mittwoch, 10. Mai 2017 10:56:56 UTC+2 schrieb Melvyn Sopacua:

> > On Tuesday 09 May 2017 14:08:44 Jani Tiainen wrote:

> > > And to use bootstrap you don't need any special package, you can

> > > do it

> > >

> > > without it just fine.

> >

> > To render a webpage, you don't need Django you can do just fine

> > typing HTML. What's your point really?

>

> I know that I can render a webpage without django.

>

> What is the point?

 

I am on your side of the fence. Please observe thread structure and quoting.

 

--

Melvyn Sopacua

[Melvyn Sopacua]

On Tuesday 16 May 2017 12:05:59 Jani Tiainen wrote:

 

> "rightway" to do things is to keep rendering (html) in the place where

> it belongs to - in templates. That's the main functionality of

> templates.

 

First, there's no single place to render HTML. Template rendering deals very poorly with nesting and recusion. The right place for those really is a progamming language.

 

Second, forms don't have to be rendered as HTML, but I agree that rendering is in principle the job of a template (but not the only place).

 

> Unfortunately traditionally Django forms have been doing things wrong

> and pushed HTML rendering to Python code - bascially to change your

> HTML you need to change Python code, which in production would mean

> deploying site again.

 

I've never experienced that as an issue (ok, maybe once). In the vast majority of cases, the changes needed to a form are not HTML related.

 

And this brings me to the point you're not seeing: if a tag renders a piece of HTML correctly for the majority of the cases, then by all means use it. For the exceptions, you can use plain HTML.

 

So, the reason I advised the bootstrap3 package, is that it produces the correct HTML 9 outof 10. Do I need it? No. Does it save me time? Yes, definitely. And it keeps structure of templates readable.

 

--

Melvyn Sopacua

[Melvyn Sopacua]

On Tuesday 16 May 2017 08:51:49 knbk wrote:

> On Tuesday, May 16, 2017 at 9:51:07 AM UTC+2, guettli wrote:

> > This is a basic fact, and AFAIK this basic question is not solved

> > yet.

> >

> > <table>{{ form }}</table> * vs * {{ form }}

>

> That question is actually answered by the documentation

> <https://docs.djangoproject.com/en/1.11/ref/forms/api/#outputting-form

> s-as-html>

> > - For flexibility, the output does *not* include the <table> and

> > </table> tags, nor does it include the <form> and </form> tags or

> > an

> > <input type="submit"> tag. It’s your job to do that.

 

Not sure if flexibility really is the original intent, but the Form class is badly named when you think of it as HTML forms.

 

It is *not* an abstraction of the HTML <form> tag, it's closest to an abstraction of the DOM HTMLFormElements collection. Once you see that distinction, things become a lot easier to grasp.

 

--

Melvyn Sopacua

[James Schneider]

On May 17, 2017 6:31 AM, "guettli" <guettli...@thomas-guettler.de> wrote:

Hi Russell Keith-Magee,

which version do you use? With <table> or without table?

   <table>{{ form }}</table> vs {{ form }}

Both of these are incorrect.

You need to wrap {{ form }} in a <form> HTML tag. If you want it in a table, use {{ form.as_table }}.

https://docs.djangoproject.com/en/1.11/topics/forms/#form-rendering-options

There is no "correct" way, it depends on your template design as to which one is more appropriate.

-James

[guettli]

Hi James,

yes, you are right. Both ways need a surrounding <form> tag. Maybe I condensed my question too much.

I don't understand the "as_table" part you wrote. AFAIK {{ form.as_table }} and {{ form }} return the same result.

Regards,
  Thomas

[James Schneider]

Hmm, it appears you're right. I mistakenly though that {{ form }} would result in something similar to {{ form.as_p }}. I haven't rendered a {{ form }} without crispy-forms in quite a while.

https://docs.djangoproject.com/en/1.11/ref/forms/api/#outputting-forms-as-html

Also tested myself quickly on a current project and verified the same.

In that case, both of those formats are valid and effectively equivalent. My original assertion about there being no "correct" format still stands, since that is based on your template design. Adding the <table> tags will place the form inside of a true HTML table. That may or may not be what you want. You may want to be more semantic if using a table and use <table>{{ form.as_table }}</table> just to make it clear that the variable is being rendered as a table, rather than relying on a default output format. That's personal preference, though, but it is slightly safer if the default format for {{ form }} ever changed, which I doubt will be the case any time soon.

Apologies for not checking myself before sending out the response. 

-James

[guettli]

No need to apology :-)

Up to now I don't use crispy forms. I think a lot of people use it. Maybe I should try it.

Regards,
  Thomas