#django

jtiai I fixed my code with the standart convention but I still do not get anything printed to the console https://dpaste.de/ydzj

lordofthekebabs: Well is the form valid?

hold on i feel stupid let me write a test

lordofthekebabs: that's a great quote

tests ftw <3

haha :)

Hi, i finaly started to write tests and need to load data into my text case. So I created a view entries in my db and exportet everything with manage.py dumpdata > dump.file. How do you load this file for your test?

mad_moses: this would be using django-style fixtures

I would recommend against using text-based fixtures

in favor of using factory functions

because files will get outdated and maintaining them can be very cumbersome

^ this

also, https://hypothesis.readthedocs.io/en/latest/ can be even more awesome

well, hypothesis is more fore fuzzing tests

I personally use model-mommy and it works fine

for nominal data

jtiai yep the form is not valid and I have found the bug but I dont know how to fix it. https://dpaste.de/6jZ6 I am trying to create a form with a choices field

most importantly I'd advise using pytest once you get comfortable writing a few tests

lordofthekebabs: If you do have a model and want to form for it, why aren't you using modelform?

jtiai because there are many models that are geting updated in a single form

ok thank you

lordofthekebabs: Still.

jtiai that is why I createad a one custom form

that has the neccessary input fields

lordofthekebabs: http://musings.tinbrain.net/blog/2015/jun/10/up...

And no, you can have million forms in same page and it will work.

let me read it a sec pls

having million ofrms in same page is not a good idea :p

Surely it is :)

(well my worst page contains 13 forms...)

Django forms that is.

but what is wrong with using

`request.POST.get('submit_btn')`

instead of `request.method == 'POST`

the first one is more readable jtiai

hello, I have another question, an import does not work as expected and I am quite confused why it does not work: http://dpaste.com/0M4G1PM any hints what could be wrong?

Because you don't need to care about which form you're dealing with.

Just feed proper data and things "magically" do work.

jtiai so do i use as many `request.method == 'POST'` as the forms in the view for example if i have two forms there will be two control flows of `request.method ==POST`

right ?

lordofthekebabs: Nope. Only one. Only one HTML form regardless of number of Django forms you render on a single page.

lordofthekebabs: what're you actually trying to do / achieve here?

let me dppase it easily jtiai doismellburning it will be more easier

got it, forget my question

django can create a test database. Am I overlooking something, or can it actually NOT create the default database?

dang`r`us: I guess it _could_, but it doesn't

I think it does for sqlite though maybe? it's been a while

pretty sure it does, but that's because sqlite does

at least for postgres, you need to create any non-test databases yourself

jtiai doismellburning https://dpaste.de/P7Hy i simply have two forms in a single view and my question is which way should I process them.

you can see the 2 ways in the dpaste

lordofthekebabs: Almost the latter one.

__latter__ ?

the second one ?

and if it is `almost?` what is wrong with it

You should use all() to check form validity as described on that blog I gave you.

Also if your froms represents models use modelforms. They make all the nice things for you.

I will I just needed to know this too and you answered it

thanks a lot

lordofthekebabs: are they *both* to be or is it "one or the other"?

one or the other

which is the correct way

lordofthekebabs: I'd strongly recommend handling them in different views

atleast which is more close to being correct *

hold on yeah why I dont just validate them in different views

Well definitely if forms are exclusive using different views is correct.

But you never said that...

is it a bad design if I create a view just for a form ?

lordofthekebabs: no

Why that would be a bad design?

I just create views for my url patterns

I taught it was the right way to go

lordofthekebabs: your statements suggest you're missing something conceptual

lordofthekebabs: how do you think your "view just for a form" would work *without* a urlpattern?

no i know that it would work without a url pattern i just taught it would be a bad design

let me code it tho thank you all for the feedback

let me try to tackle it and see if i can fix it

thanks

just more urls and views...

but two forms are in a single page

wouldnt something break down

if two views are rendering the same template

lordofthekebabs: I think you're conflating Forms (the Django concept) and HTML forms

let me try it okay okay i will come back if something breaks down horribly

lordofthekebabs: so for example a common pattern on a site of mine is to have a login HTML form at the top of every page for unauthenticated users

okay

lordofthekebabs: this is part of the base template, and POSTs to the login URL

oh yeah i have the same thing for logged in users for a log out

yeah i got it i will try

thanks a lot

lordofthekebabs: I suspect your logout thing isn't a form

oh maybe it is

yeah it is the core auth.sys

but still it is pointing to a view

lordofthekebabs: note that we might have reached this point much sooner if you'd provided more context with your initial questions btw ;)

like, full examples

doismellburning well yeah but the inital question was answered simply. I asked like 5-6 additional questions :)

thanks a lot tho for taking your time jtiai doismellburning

np, g'luck!

background pain is nailing any focus I have, so questions are awesome distractions

Awesome. I broke our self registration system when implementing GDPR crap.

jtiai: that's a nice surprise on a Fridau

-u +t

dammit

Well fortunately I know the fix and have still 40 mins to patch it everywhere.

Hi. I'm having a bit of a problem defining my models. Using http://dpaste.com/2A62J60 I get errors like "(fields.E304) Reverse accessor for 'Relation.source' clashes with reverse accessor for 'Relation.target'." Also the hint to "add or change a related_name argument to the definition" of those fields, but even reading the documentation, I can't quite wrap my head around it. Can someone ELI5 it to me, or maybe hint

at a better way of modeling this?

both source and target point to the same model

so Django's ORM can't figure out which is which from the Fact model

it can figure it out, it can't guess the name of inverse relation

there is a default name for the reverse relation (read Fact -> Relation)

this default name can't be used for both FKs

so give a different related_name attribute to at least one of those FKs

set related_name manually or use "+" to ommit inverse side

Do I lose anything by not having an inverse relationship?