#django

¯\_(ツ)_/¯ seems equivalent to me but, sure, whatever

if it works, it works

pjs: that would be my preferred approach

Koterpillar: if i take out abspath i get an error saying Resume has no len()

__love__ My method just saves a query or two. I can't shake habits from the 90's apparently

mandeep: looks like you're passing wrong objects to everything

hmm

mandeep: what do you *want* to do at that line?

pjs: it does? doesn't the article view and the category view both perform queries?

Koterpillar: pass the uploaded file into another uplod box

mandeep: well, 'cv' is not an uploaded file

__love__ Yes, but now you're talking about adding additional queries to the router view

Koterpillar: what can i change to have cv become an uploaded file?

pjs: hmm, yeah, i guess. or just pass the actual collected object into the final view

pjs: seems like that final view would never need to actually perform a query itself

mandeep: I can't see the code around that

__love__ That's true.

Koterpillar: i dont think anything in the script needs to be changed since it's django independent, right?

pjs: you just gotta know what kind of object you have. easy enough

mandeep: how would I know if it is if I can't see it?

__love__: what advantage would making a query first give?

Koterpillar: the script works if i use request.POST.get('cv')

Koterpillar: it's more about controlling where the queries are done. do them early and don't do them again

__love__ Right, that's no issue. Just don't see advantage to change the logic of 2 working views for no real performance gain, or code logic gain.. But who knows, maybe once I write this stupid router view it'll make more sense. I'll keep you posted

Koterpillar: here's the script: https://dpaste.de/ZxtJ

__love__: looks like in pjs' case, the queries in the views are early enough

pjs: ¯\_(ツ)_/¯ this is what 2 minutes of contemplation gets you

hah!

fair enough

mandeep: where is django_view() called? I can't deduce what 'cv' and 'resume' are here

Koterpillar: sure but there's a query in each view and you have to check for the 404s. w/ my method, there's one "query" (yes, it's two queries but a single queryset in the end) and you don't have to catch 404s. all of the logic is encapsulated in the router view

Koterpillar: in the views.py. cv is the argument name in line 58 of the script. resume is from the views.py

__love__: disagree, the logic leaks from the article/category views: what if get_object_or_404 has more parameters that control how the object is found?

Koterpillar: ¯\_(ツ)_/¯ i don't know that as it hasn't been shared and that should probably be addressed in a model manager, not a view

mandeep: ok, so instead of the uploaded file you are creating a Resume object from it

__love__: issue still stands, the article view should know how to find the article, not the router view

Koterpillar: not really. the view should be thin and dumb. the model should know how to find an article, the view should just handle the logic of getting the instance to the template. which it would still do.

Koterpillar: isn't filefield what i need to use?

mandeep: you are not using a filefield

(model, model manager, querysets, etc)

__love__: the article view will at least call the right manager method

__love__: that part of logic should stay there

sure. but _any_ view can call that

Koterpillar: i have a filefield in my models.py

if the router depends on a valid record being found, that logic belongs in the router

s/router/router view/

and it's being called in the views.py

__love__: in fact, the router view can be made generic, it should just call several views until one succeeds

__love__: why should _router_ know about the right Article methods to call?

yeah, that won't get out of hand any time soon

well, we're just fixing a limitation of the stock router

mandeep: what does this line do? resume = Resume(request.FILES['resume_upload'].read())

Koterpillar: reads the uploaded file

mandeep: and then?

mandeep: here's the part that "reads the uploaded file": request.FILES['resume_upload'].read()

Koterpillar: and then passes it to the model?

mandeep: OK, so why do you pass the model to django_view() and ultimately to abspath() then?

Koterpillar: really, i think it's a wash. both approaches are fine and it just depends on how you want the logic fractured.

for now, though, it's time to go have a beer and play a game

__love__: ++

Koterpillar: im not sure how to pass the file from the model to django_view() and abspath is a carryover from a prior implementation of request.POST.get('resume')

mandeep: why do you pass the file to the model?

Koterpillar: i was having memory issues

in what sense?

Koterpillar: i cant remember the error, but it was something about file not able to be saved in to memory

Koterpillar: InMemoryUploadedfile does not support indexing

so you decided putting it into Resume() will solve it. However, django_view() expects a file name, not a Resume object, so you have to figure out how to get your file back

Koterpillar: any suggestions in what to learn to accomplish this?

mandeep: ah, looked at the Resume model. Here's what you need to read: https://docs.djangoproject.com/en/1.9/ref/model...

mandeep: and https://docs.djangoproject.com/en/1.9/topics/fi...

Koterpillar: many thanks

mandeep: I would also suggest learning more about types in general - can't recommend anything, but any Python book would go into this

Koterpillar: im familiar with types just dont know much about django

when you extend User model by following the docs, should the new model be in its own app? https://docs.djangoproject.com/es/1.9/topics/au...

Yes.

mattmcc: as opposed to being together with other models in your app?

As opposed to being in the same app as User..

I'm wondering if it should be in the same app as one of my project app

or should I startapp UserProfile

Well, if you already have an app with other user-related stuff in it..