Suggestion: Change attribute (column) from "text" to "body"
In blog/model.py it seems there would be a better name than text for the body of the blog post, just because "text" is so often considered to be a type in so many languages. The fact that the Django designation of the field type is TextField lends support to that contention.
(In addition, perhaps a better word than "Post" when one uses "post" and "get" as part of http.)
In English, at least, it would seem body and entry or even blog_text and blog_post might help disambiguate. (There are probably several other good choices there. body and entry were just the first two synonyms to pop into my head.)
Then again, for a one-day tutorial, I suppose it doesn't matter. But it might confuse folks later on.
Hmm ... "body" on the other hand could be confused with the <body> element of an HTML document. :neutral_face:
"blog post" (rendered as BlogPost as class name / Django model name, blog_post as variable name / parameter name) instead of just "post" would work though and would indeed remove some ambiguity with the English verb "post" (and HTTP verb POST). :+1:
Hmm ... "body" on the other hand could be confused with the
<body>element of an HTML document. :neutral_face:
True enough. It still felt less generic / more semantic than "text".
"blog post" (rendered as
BlogPostas class name / Django model name,blog_postas variable name / parameter name) instead of just "post" would work though and would indeed remove some ambiguity with the English verb "post" (and HTTP verbPOST). +1
Well, I'm "as dumb as a post", :wink: but I like it.
How about content?
content sounds good to me! :+1:
I like content but would gently consider, if going that way, changing {% block content %} in the template to something else. {% block entry %}? {% block post %}? {% block dispatch_from_the_home front %} :wink:? {% block article %}? Something that encompasses a title, date and content.
I like
contentbut would gently consider, if going that way, changing{% block content %}in the template to something else.
Eek, good point!
{% block entry %}?{% block post %}?{% block dispatch_from_the_home front %}:wink:?{% block article %}? Something that encompasses a title, date and content.
None of these seem convincing to me. Remember that our base template
<body>
<div class="page-header">
<h1><a href="/">Django Girls Blog</a></h1>
</div>
<div class="content container">
<div class="row">
<div class="col-md-8">
{% block content %}
{% endblock %}
</div>
</div>
</div>
</body>
is used for both, the post_list template (where the content block will be the list of all blog posts) and the post_detail template (where the content block will be a single blog post). So we really need a term as generic as "content" to capture both use cases of that block.
OK... going back to my original thought... instead of an attribute / column named text or body... how about article or story?
Given Django's history in the news business, a newspaper entry is often defined as a story and it would seem to be a word that doesn't conflict with anything else...
Meanwhile, article actually maps nicely to the HTML5 tag <article>.
Though I usually think of a title child element or attribute of an article or story, rather than a sibling, I still like them both better than text.
Also, semantically good but "typographically" bad content (a post) could be an entry in the contents (a list of posts). Hazardous because people would forget to leave off or add the "s" at the end, depending on the context...
I've filed a separate issue (#1648) about "post" / "blog post", as that seems independent of the name of the model field currently named "text".
Also, semantically good but "typographically" bad
content(a post) could be an entry in thecontents(a list of posts). Hazardous because people would forget to leave off or add the "s" at the end, depending on the context...
"contents" seems to be a valid English word, so why not? Granted, it's a bit subtle, but still better than keeping these names exactly the same or than choosing a word that doesn't really match the intended meaning.
@das-g I bow to the community on that. :wink: It seemed good enough to include as a possibility, but I did want to make the caveat that the subtle difference between content and contents might be something to warn people to be aware of. Easy to gloss over in documentation that and trip people up. (Without sufficient caffeine, it would trip me up. And there might not be sufficient caffeine to prevent it.)