#django

ovalseven8: Usually you should define your own loggers.

Django logging is just plain pytho logging. no magic there.

jtiai, You mean for every module?

And yes, you have to use getLogger in every module.

logging.getLogger(__name__) is usually what you want.

That way you can benefit from the hierarchical nature of logger names.

Okay, however, it does not work by default.

"does not work"?

jtiai, Seems like there is no handler for e.g. "appname.module"

Well you need to define that one in settings.

Yeah, I just thought that would work by default

jtiai, mattmcc, Do you have then "logging.getLogger(__name__) at the TOP of every module in your django project?

Not every.

Well, the ones that I need to log messages from.

there's also the root logger config

and propagate

mattmcc, "__name__" is usually "appname.module", do you define a handler for every app then?

I do, yeah. Although you could simplify it by sticking a prefix on.

getLogger('myapps.' + __name__) or whatever.

What is wrong with "logging.getLogger('django')"?

too generic?

It's used by, y'know, Django.

You almost certainly don't want to combine your own logging messages with the ones Django will generate.

and you can't configure logging differently for different parts of your project

Logger names don't have to map to Python modules at all, you can make up whatever base name you want for your apps.

Thanks, y'all. Definitely something for the Django docs. :)

Well, it's not Django behavior at all, it's all Python logging.

By the way: When you remove the __init__ file in your app, "__name__" still returns "appname.module"

All the Django-specific stuff is documented at https://docs.djangoproject.com/en/2.1/topics/lo...

mattmcc, Is using something like "logging.getLogger('myProject.' + __name__)" common? I'm asking also because perhaps I can find a way to not have to write 'myProject' in every file

ovalseven8: Well, you can't have it both ways. Either you prefix the logger name in every file, or you spell out each top-level module in your logging config.

The latter is certainly less work if you have a few apps that have a lot of files.

But there's something to be said for a common namespace across your apps that lets you manage their logging uniformly.

mattmcc, I've heard of the ''-logger (catch-all).

Ah, solution: https://stackoverflow.com/a/22392523

hey guys i created a view https://bpaste.net/show/469fd268a60d

having looked a bit deeper , it seems i could have used django.views.generic.edit.CreateView

under what circumstances would it have been better to use CreateView

i dont really get the reasoning behind which i SHOULD have chosen

both ask for a form

both validate

In general genereic views are meant to remove boilerplate.

ah..so for my view which is just an enquiry form...would you have used a generic view jtiai

I have never used generic views :)

ah ok ...you want control over like everything

There's a FormView class that'd probably be useful.

My apps are mostly SPA and uses REST interfaces.

the formview class ....you can have model forms so that too is a bit tricky

if you already got models

ah it seems that most of my views the function views ..i could have used formview

If you're working with a model, then I wouldn't use FormView.

hmm ...when i was working with a model..eg for a cv send form...i used a function which called a template...but then created a forms.modelform for validation and saving

True, and you had to write a code for all that.

If you have tens of forms you would be writing pretty much the same boilerplate over and over again.

ah yes

i've got foreignkey in admin inline and extra=3, and for each form foreignkey options are taken from db, i don't see option for caching it

Yeah, out of the box it re-queries those choices for each form in the formset.

mattmcc, how do you walkaround that? :)

btw. i've seen that select2 is integrated with django2.x, can it be enabled for inline, maybe this would solve that in my case?

mattmcc, raw_id_fields does the job

anybody tried perl FW before?

I mean web frameworks