#django

hello! question: have a request object. need a response object (say to "simulate" a http request). how to achieve that? :D

nnscr: that depends on your requirements, but one option is to simply call a view function

knbk: yep, but that doesn't really seem clean. i need it a step further

and that's already all of my requirements. resolve request to response object

that is exactly what a view's job is

oh and it should work with django rest framework, but i assume that that shouldn't make a difference

what do you mean with a step further?

well, something like process_request(request) -> Response ^^

so, not sure why you think that's unclean. what is your higher level requirement?

it's fine if i need to call the view, it just seems a bit unclean

but probably i'm just beeing too picky again

what kind of response do you want?

nnscr: why do you want such a thing as non-view? :)

nnscr: I mean, what's the use case?

uh, a http response i guess? :D with headers, response code, body and so on... ^^

I'm trying to find a good explanation of what exactly 'app_label' is, how it's created (autmagically?) and what use caes it has.

nnscr: we can really help you much better if you tell us what your actual (high-level) problem is

response = HttpResponse('') <-- that should do it, then?

nnscr: otherwise, my best answer is: ``def process_request(request): return HttpResponse()``

Is there an easy way to migrate app data from MySQL to Postgres? Including user data?

having a dict (from json) that contains the http verb and url and needing the response as if a browser would have called it directly

Beef_wgtn: depends on the details. dumpdata / loaddata might work.

nnscr: sounds like you are mocking a rest API for documentation...

moldy: thanks I just found a relevant post on that. Cheers

Lynoure: nah, i'm trying to call a rest api from a channels websocket, actually

nnscr: any reason in particular why you don't want to perform a real http request?

moldy: i was just playing around with channels and thought that would be something cool to do... ^^ we're about to develop a SPA with django as a backend and wanted to avoid the tcp, http overhead

svg: it's a unique identifier for an app in INSTALLED_APPS, it defaults to the innermost module containing models.py, e.g. for apps.core.models it's 'core'

i know it's not much and doesn't really matter, i just haven't expected it to be that hard

nnscr: I suspect this is only hard because of the artificial limitations (see e.g. knbk's answer or moldy's)

i'm coming from the symfony environment and passing in a request somewhere to directly get a response without ever seeing who returned the response is a no brainer there

nnscr: if you have a ReST API, it's designed to be used via HTTP, not as a direct python API.

knbk, thanks

moldy: yep, but even if it wasn't a rest api, i think there would still be use cases to render a view manually

nnscr: i think your real problem is how to **construct the request**? if so, take a look at RequestFactory(). i'd probably just use the `requests` lib to perform an actual HTTP request, though.

but i don't want to argue with you guys, i'm fairly new to django and i guess i just don't understand it yet

is there a way to find out which other apps (besides the ones I specifically write myself) need access to the database? I'm looking at two apps with their own db, and writing a db router

nnscr: a view is just a callable, you can call it like any other python callable: ``response = myview(request)``

moldy: yep, i know, thanks. does that also work for class based views?

nnscr: it works on the result of calling .as_view(), yes: `´myview = MyCBV.as_view(); response = myview(request)``

note that doing this would skip middleware etc.

strictly speaking, class-based views are not views. the result of calling ``._as_view()`` is the actual view.

moldy: so i can't just use resolve(url) and call the result no matter if it's an class or function view?

knbk: okay... that doesn't sound good

moldy: alright, good to know

what knbk says, plus you bypass the webserver in front of your app and whatnot

nnscr: ``func, args, kwargs = resolve(url); response = func(request, *args, **kwargs)`` works for any kind of view

i don't care if i bypass the webserver. but i'd like to have a close as possible stack as when doing a regular request

just use requests and do a real http request, or split your ReST api into a python and an http part

moldy: that's not an option. right now i'm just playing around with django and see how comfortable i feel with it. doing this manually-calling-rest-thing is just for science, actually

ok, then knbk gave you the recipe

yeah, i've already did it that way and it worked okay. just thought there would be a better way

including middleware for example

it's generally a bad idea, that's why Django doesn't make it easy

(there's the test client which calls middleware, but it's for testing only and full of security holes)

well, symfony has something called sub-requests where you can pass a custom request in to the kernel which delivers you a response in return (not that i'd want to start a framework war)

(there are reasons i'm leaving the php world for web development after all ^^)

i agree that it has limited use cases, but still i thought it should be possible somehow. but however, i'll just use the view directly for the moment and think of something else when we actually start the project

thank you guys anyway!

hallo

I'm reading through https://docs.djangoproject.com/en/2.0/topics/se... and there is constant reference to a certain "proxy"

what is this proxy? wsgi?

or like an apache server?