{"database": "pelican", "table": "content", "is_view": false, "human_description_en": "where author = \"ryan\", published_date = \"2019-11-03\" and \"published_date\" is on date 2019-11-03", "rows": [["ryan", "technology", "From [Classy Class Based\nViews](http://ccbv.co.uk/projects/Django/2.2/django.views.generic.base/TemplateView/)\nthe `TemplateView` will\n\n> > Render a template. Pass keyword arguments from the URLconf to the context.\n\nIt is an extended version of the `View` CBV with the the `ContextMixin` and\nthe `TemplateResponseMixin` added to it.\n\nIt has several attributes that can be set\n\n  * content_type: will allow you to define the MIME type that the page will return. The default is `DEFAULT\\_CONTENT\\_TYPE` but can be overridden with this attribute.\n  * extra_context: this can be used as a keyword argument in the `as\\_view()` but not in the class of the CBV. Adding it there will do nothing\n  * http_method_name: derived from `View` and has the same definition\n  * response_classes: The response class to be returned by render_to_response method it defaults to a TemplateResponse. See below for further discussion\n  * template_engine: can be used to specify which template engine to use IF you have configured the use of multiple template engines in your `settings.py` file. See the [Usage](https://docs.djangoproject.com/en/2.2/topics/templates/#usage) section of the Django Documentation on Templates\n  * template_name: this attribute is required IF the method `get\\_template\\_names()` is not used.\n\n## More on `response_class`\n\nThis confuses the ever living crap out of me. The best (only) explanation I\nhave found is by GitHub user `spapas` in his article [Django non-HTML\nresponses](https://spapas.github.io/2014/09/15/django-non-html-\nresponses/#rendering-to-non-html):\n\n> > From the previous discussion we can conclude that if your non-HTML\n> response needs a template then you just need to create a subclass of\n> TemplateResponse and assign it to the response _class attribute (and also\n> change the content_ type attribute). On the other hand, if your non-HTML\n> respond does not need a template to be rendered then you have to override\n> render _to_ response completely (since the template parameter does not need\n> to be passed now) and either define a subclass of HttpResponse or do the\n> rendering in the render _to_ response.\n\nBasically, if you ever want to use a non-HTML template you\u2019d set this\nattribute, but it seems available mostly as a \u2018just-in-case\u2019 and not something\nthat\u2019s used every day.\n\nMy advise \u2026 just leave it as is.\n\n## When to use the `get` method\n\nAn answer which makes sense to me that I found on\n[StackOverflow](https://stackoverflow.com/questions/35824904/django-view-get-\ncontext-data-vs-get) was (slightly modified to make it more understandable)\n\n> > if you need to have data available every time, use get_context_data(). If\n> you need the data only for a specific request method (eg. in get), then put\n> it in get.\n\n## When to use the `get_template_name` method\n\nThis method allows you to easily change a template being used based on values\npassed through GET.\n\nThis can be helpful if you want to have one template for a super user and\nanother template for a basic user. This helps to keep business logic out of\nthe template and in the view where it belongs.\n\nThis can also be useful if you want to specify several possible templates to\nuse. A list is passed and Django will work through that list from the first\nelement to the last until it finds a template that exists and render it.\n\nIf you don\u2019t specify template_name you have to use this method.\n\n## When to use the `get_context_data` method\n\nSee above in the section When to use the `get` method\n\n## Diagram\n\nA visual representation of how `TemplateView` derives from `View` 1\n\n![TemplateView](https://yuml.me/diagram/plain;/class/%5BTemplateResponseMixin%7Bbg:white%7D%5D%5E-%5BTemplateView%7Bbg:green%7D%5D,%20%5BContextMixin%7Bbg:white%7D%5D%5E-%5BTemplateView%7Bbg:green%7D%5D,%20%5BView%7Bbg:lightblue%7D%5D%5E-%5BTemplateView%7Bbg:green%7D%5D.svg)\n\n## Conclusion\n\nIf you want to roll your own CBV because you have a super specific use case,\nstarting at the `TemplateView` is going to be a good place to start. However,\nyou may find that there is already a view that is going to do what you need it\nto. Writing your own custom implementation of `TemplateView` may be a waste of\ntime **IF** you haven\u2019t already verified that what you need isn\u2019t already\nthere.\n\n  1. Original Source from Classy Class Based Views \u21a9\ufe0e\n\n", "2019-11-03", "cbv-template-view", "From [Classy Class Based\nViews](http://ccbv.co.uk/projects/Django/2.2/django.views.generic.base/TemplateView/)\nthe `TemplateView` will\n\n> > Render a template. Pass keyword arguments from the URLconf to the context.\n\nIt is an extended version of the `View` CBV with the the `ContextMixin` and\nthe `TemplateResponseMixin` added to it.\n\nIt has several attributes that can be set\n\n  * content_type: will allow \u2026\n\n", "CBV - Template View", "https://www.ryancheley.com/2019/11/03/cbv-template-view/"]], "truncated": false, "filtered_table_rows_count": 1, "expanded_columns": [], "expandable_columns": [], "columns": ["author", "category", "content", "published_date", "slug", "summary", "title", "url"], "primary_keys": ["slug"], "units": {}, "query": {"sql": "select author, category, content, published_date, slug, summary, title, url from content where \"author\" = :p0 and \"published_date\" = :p1 and date(\"published_date\") = :p2 order by slug limit 101", "params": {"p0": "ryan", "p1": "2019-11-03", "p2": "2019-11-03"}}, "facet_results": {}, "suggested_facets": [{"name": "published_date", "type": "date", "toggle_url": "http://search.ryancheley.com/pelican/content.json?author=ryan&published_date=2019-11-03&published_date__date=2019-11-03&_facet_date=published_date"}], "next": null, "next_url": null, "private": false, "allow_execute_sql": true, "query_ms": 12.327545322477818}