#django

what's the word on the streets for 1.7 final :-)

RSN

RRRSN

YEY!

If only freakboy3742 and those other lazy core devs wouldn't galavant off to conferences instead of slaving over releases.

scandalous of them

seriously, we pay them so much!

anyone know if they're recording the talks at djangocon this year?

don't they most years?

they did at Django/Py-ConAU

oh, right on

pyvideo.org good way to find stuff related to python!

xterm: thanks!

hey, is there a way to filter a queryset on model?

pardon?

because i have a model which inherits from another model, but it's shown in the same change_list

i want to filter out the inheriting model

...

MTI? or abstract inheritance?

Find the PKs of the child model, and exclude those from the QuerySet of the parent model, assuming concrete inheritance

the class def for the inheriting model is: "class ModelName(BaseModel):"

so i think it's concrete inheritance

only if BaseModel doesn't have Meta.abstract = True

doesn't

I'm facing a weird issue in django 1.7. I'm using a custom module to host migrations for the `auth` app. I'm adding 0002 custom migration to add some fields to the auth.Groups table. Here is my 0002 migration for auth app https://gist.github.com/owais/cabc53a79e7b092457cc

When I run `migrate auth 0001`, it also creates the fields that are specified in 0002.

prohobo: so it's multi-table inheritance

and thus almost certainly not what you think

it does not make 0002 as migrated which if correct but it creates those fields when running 0001. So while running 0002, django always complains that the fields already exist

this is django 1.7. Looks like a bug to me.. or am I missing something?

owais: are you using the latest 1.7 from git? or rc3 ?

FunkyBob, latest from 1.7 stable branch

FunkyBob, https://github.com/django/django/tree/stable/1.7.x

Is it a good idea to make views as classes? e.g. TemplateView etc

or is it preferable to use render(...)

argoneus: when it helps

FunkyBob: but if it's a simple case

is there any difference between def bla(TemplateView): template_name = "bla.html", versus def bla(request): render(request, "bla.html")

sure

render is probably faster,

and is a view itself, instead of requiring you to call the "as_view()" view factory

hmm

so the classes should be used if it's more robust?

time to bench render() vs TemplateResponse :o)

argoneus: I never said that

Stupid question - When I do have FileField in my model how I can get original name of file uploaded, not the mangled one that get's saved?

FunkyBob: but I can't think of an example "when it helps"

jtiai: you can't unless you choose to save that name elsewhere

argoneus: then don't use them

my view just gets information from models if needed, fills the context with values and returns a template

why would someone need a class?

I mean, I'm sure there's a use for it since everyone seems to use classes

I just can't put my finger on it right now

the CBV replaced the old function based GENERIC views

they provided a more flexible, cleaner framework to let people hook into the interfaces and customise how these GENERIC views behaved

by using class method overides through inheritance, instead of bodgy callback hacks

oh

there's a grat talk by freakboy3742 at PyConAU about this

FunkyBob: so as_view is more "modern" than render()?

no

as_view() is a part of the Class-Based View design

you must call it on your CBV in order to get the view function that will be invoked

or were you talking about creating your own class-based view design?

If you use CBVs, it's nice to read the source of as_view()!

it's not :o)

well

I'm a wee bit confused right now

argoneus: about?

so there's 3 ways? render(), return HttpRequest, and generic templates (TemplateView...)?

render() is just a shortcut

here's a question, why do *render* and CBVs have different return types? (TemplateResponse vs render_to_string())

it does get_template(), creates a RequestContext, and then return HttpResponse(template.render(context)) ... more or less

oh, I see

kezabelle: yeah, I was thinking of submitting a patch to make render use TemplateResponse :)

so I can use either the function based approach, or the generic templates, or CBV?

argoneus: generic templates?

FunkyBob: please do.

CBV are the Class-Based Generic Views

(well, mostly)

wait

makes little sense, and the API is different from a testing perspective, which is quirky

what did you say

"old function based GENERIC views"

what does that mean?

so, there were "generic" views -- "list", "add", "edit", etc

before Django 1.4, all the generic views were function views... not class based

they were function based views.

ohhhh

they were replaced with the Class Based Generic Views

so whenever I use a class with a generic view

it's already CBV?

as of … 1.3? 1.4? CBVs came in, and alongside them came Generic CBVs to replace the old FBVs.

class based view, right

"from django.views.generic" <--- all CBV now

so when you talk about TemplateView... that's a CBGV

I see

is it preferable to use CBV or render()? I want a page that uses a template and shows data based on GET requests

I guess using a CBV will be easier?

will it?

not from what you've described

I just specify template_name and def get(...)?

no?

you mean template_name and get_context_data()

I'm even more confused now

isn't this what get() and post() are for?

at least that's what the doc seems to imply

I think you're better off just using a function based view and forget the rest of the stuff exist. (Atleast for now)

get() and post() are for handling how to react to those HTTP actions