#django

do django form properly provide a datetime widget when the model field is DateTimeField?

No, that's up to you.

This is on purpose. https://code.djangoproject.com/ticket/16630#com...

docs say `Default widget: DateTimeInput`

is that on the admin ui?

looks like I can provide input_formats to it, but then I need to explicitly define the form in form.py no? and I can't use the fields variable in the view anymore

mmm, no that arg already has a default value

so I'm meant to supply a full datetime string to the form from the UI? no way to attempt html inputs from the django side?

html5

If you want the html5 date picker, you can customize how the widget is rendered, or subclass it to make your own.

Adding on a JS date picker is usually pretty easy too.

I'm just using a string for now, the browser keeps previous inputs in history

help on this error https://gist.github.com/morenoh149/a888ea204551...

event-detail is a named path in urls.py I can even navigate to it just fine event/3

this is after submitting the event form

Im using form.as_p option, how could I add/control the css/classes of each retrieved field form ModelForam

*ModelForm

N

converge: you override it with converge https://docs.djangoproject.com/en/2.0/topics/fo...

disregard the first part of the message

gah, fixed my issue, needed to do 'polls:event-detail' as I'm using url namespacing

morenoh149, thanks !

jarshwah: btw -- https://docs.python.org/3.6/whatsnew/3.6.html#p...

does form_valid enforce csrf?

no

csrf is handled in middleware

I'm writing a phone app, should I query a page to get the csrf token?

yes

I generally do that on my "login check" url... so you make it do, say, GET /auth/ and check if it's logged in

that ALSO has @ensure_csrf_token on it

then if youre not logged on, you POST /auth/ or whatever

kill two birds with one stone

don't kill birds. birds are nice people

you can kill me. i'm not good people

thanks, sounds like I need to tackle auth next

is the app the only client?

Hey if I have revisions of an object at different times, anyway to efficiently find out the value of an attribute at a given time X?

depends on how you're storing revisions

I am using django-reversions so I can retrieve them from a list

totallyserious: how do you it now?

i iterate through all the reversions and then find out the latest reversion before a given datetime

but it's seriously slowly my application

that's not a list, that's a query set

but no matter

you should be able to filter by time, no?

yes

wo why do you have to iterate?

is there a name for this type of data retrieval? I believe there should be tools out there that solves this for me

believe harder, maybe something will materialize ;)

s/wo/so/

well?

EDIT: I am iterating through all the objects and retrieving the data in O(1)

but it's still a slow process because of the multiple db calls

why multiple?

totallyserious: again... why are you iterating, if you can retrieve a revision by date?

let me clear up the confusion

You can do more complex queries using reversion.

I misspoke when I said I have to iterate

I meant for each object I query the latest revision and access the attribute. I hvae to do this for all instances of that object

so use get_for_model?

You can do it all in one query - but it's not necessarily trivial (because it uses generic relations)

hey i am createing a job model for job specs. ..within this model i will hae the name of hte client who gave me the spec...and also things like skills, salary etc.

schinckel: can you elaborate on this?

the thing is when i display the job form for internal staff...not only do i want the client name, i want the client address , tel, email

but they are part of another model

in django ...i know i will need to define the client name as a foreign key on my job model

but will i also need to define the client telephone number email address etc within my job model ?

as they are already defined on the client model

eb0t: by that logic everything would end up in one table

and not sure if i need to define them again in the job model aslo as foreign keys

eb0t: ideally you don't duplicate _any_ data in your models

hop: are you saying that when displaying the form.....to be rendered for job spec....that i pull data inot the form from several models

eb0t: are you maybe talking about model forms? those are two different things

hmmm...not sure i know that model forms base their fields on an existing model

but im happy to construct a form that bases its fields on multiple models

or is that bad news

totallyserious: You can use prefetch_related('object') on a reversion.Version queryset. That will possibly be part of it - but that works on going from Version object to the other object.

eb0t: no it's not bad news. why should it be?

But that may not be that useful for you - if you have versions all of the same type, you may be able to do a prefetch_related on that...

erm ..i really dont know

eb0t: there's also inline forms, but maybe stick to plain forms until you get the hang of it

eb0t: don't assume the worst, just because you don't know ;)

yes i think i will...thanks ...ill try and knock something together and see if i can get it working

it's just code. trying never hurts

yes ...its a bit daunting but has to be sorted one way or another

you were saying earlier that ideally you dont need to duplicate any data in your models

but isnt using a foreign key a kind of duplication

No, it's a reference.

eh? how so?

(or, a relationship)

ah so do you in the model lets say for the job spec....i will need a foregin key to the client that gave it to me ..

but when i render the form ....i can just get the other info from the client record

so i dont need to put the telephone number and email of the client into the job record

s/record/model

totallyserious: I have a snippet here to get all Versions for a queryset, but I'm not sure it can be done as a prefetch_related.

eb0t: do you really want to be able to change the client data in a job form?

totallyserious: You might be able to do a prefetch if you create a reverse relation on the target object though.

no ..but the job must be linked to that particular client

eb0t: i mean, you're basically correct, but from a ui standpoint it sounds a bit iffy

eb0t: there are also choice fields, etc.

yes i have read a little about that field ...but there may be lots of clients so i dont really want to go that route

i mean potentially hundreds

eb0t: you can go hog wild with autocompletion ajax foo

eb0t: but i don't see how _not_ using a choice field would make it easier to choose a client

when the staff member puts in a job ...they enter the business name and the contact

and lots more information