#pyramid

inklesspen: why'd you get rid of the def __json__ in the models/__init__.py in mimir?

inklesspen: nevermind, I didn't see mallows.py when I clicked changes, I guess marshmallow is what's doing the magic

inklesspen: though I'm curious why you changed

vyndion: hah

sorry if I'm too, well, 'up your ass'

just wanted to learn more about rpc

vyndion: ok.

so

you have a writeup

and each writeup has many posts

when you're fetching a writeup, you probably want to include some details about its posts

but not the whole thing

and certainly nothing about its own children

right?

yeah, too much

but with a __json__ method, each object can be serialized in only one way

ahhhhhhhhhh

using the mallows.py, when I serialize a Writeup and its children, I can say i want only these certain fields from its children

mallows lets you

gotcha

but when I serialize a post by itself, i get the whole thing

last question, and def more an rpc question

def save_writeup(request, writeup):

I get request, but where does writeup come from?

like is it attached somehow?

from https://github.com/Pylons/pyramid_rpc/blob/mast...

it's a view mapper

the pyramid_rpc viewmapper takes the rpc args and passes them into the view function

(they're also present as a request.rpc_args property)

so writeup is an argument supplied to save_writeup

yes

maybe I'm asking the wrong thing; the user is saving that writeup. how does it go from the user's browser to the rpc endpoint?

like

sure

to become an argument

ok.

so in the frontend, some component triggers this action: https://github.com/inklesspen/mimir/blob/master...

you follow what I'm asking? like the answer could be 'javascript magic'

that calls my javascript jsonrpc client with a method name of 'save_writeup' and a single argument, which in this case is a JS object representing the writeup

the jsonrpc client uses that to assemble a jsonrpc request according to the spec (http://www.jsonrpc.org/specification) and makes an ajax POST call to /api, which is the url of my jsonrpc api.

now the route predicate which pyramid_rpc installed on that route starts running: https://github.com/Pylons/pyramid_rpc/blob/mast...

that route predicate calls setup_request, which looks at the information in the request and determines yes, it is a json-rpc request, for the method 'save_writeup', with args of thus and such.

it sets those properties on the request for later, and returns True, which tells pyramid that the request matches this route.

pyramid then considers all the view functions installed for this route

most of them have a MethodPredicate configured: https://github.com/Pylons/pyramid_rpc/blob/mast...

which is true if the request's rpc_method matches the method specified for that view.

if it matches, pyramid picks that view as THE view for handling this request.

then pyramid notices that there's a view mapper configured for the view. (pyramid_rpc installs the mapper which I linked to above by default, but you can override it)

the view mapper is responsible for taking whatever view function i've written and converting it to one which matches pyramid's preferred calling convention

pyramid wants a view function to take two arguments: context and request

but my function takes a request argument and a writeup argument.

so the view mapper wraps around it. it basically throws away the context (because that's also present on request as request.context) and then inspects the view's function signature

it sees that there is an argument called 'writeup' and one positional argument in the rpc_args

so it matches those up

and then calls my view function with that argument

that argument, writeup, a JS object supplied when you did that ajax POST

yeah.

the JS object originates within the frontend react app, but i didn't figure you were asking how that worked out

there's this spot where 'novice' knows nothing and 'journeyman' can understand an explanation like you just said

ok

but then the 'journeyman' only realizes 'holy shit, am I ever going to have that level of working knowledge'

ie, mastery

i didn't really explain route and view predicates

but those are discussed in pyramid docs

no, I totally understand

what you said, and thank you for it

just a lot of stuff :)

also the main reason i know how pyramid_rpc works internally is that i made some changes to it

to support batched requests

think of it like a compliment =]

the code isn't precisely simple, but it's not too complex either

jsx looks so splotchy sometimes ><

inklesspen: not necessarily looking for an explanation, but can you point me to the area where react turns the object into writeup? is it https://github.com/inklesspen/mimir/blob/master... which then turns 'value' into it?

from frontend actions

writeup is just a positional arg

let {'foo': 'bar'} be the JS object

i call jsonrpc('save_writeup', [{'foo': 'bar'}])

which bundles that into a JSON object representing the rpc call: {'jsonrpc': '2.0

which bundles that into a JSON object representing the rpc call: {'jsonrpc': '2.0', 'id': 1, 'method': 'save_writeup', 'params': [{'foo': 'bar'}]}

gotcha

it only becomes writeup when the viewmapper is matching the positional args against the positional args accepted by my view function

however, I _could_ have passed a JSON object of args instead of a JSON array. that's also legal in the spec: {'jsonrpc': '2.0', 'id': 1, 'method': 'save_writeup', 'params': {'writeup': {'foo': 'bar'}}}

in which case the viewmapper would treat it as a keyword arg instead of positional.

understood

there's a bunch of moving parts in mimir, especially with react stuffs, glad I asked

ok, but that's nothing to do with mimir

that's just how the jsonrpc spec works

raydeo (et al): Is waitress culturally linked to pyramid in some way?

I just meant it has a ton of folders and files ^^

jMyles: it was implemented by the same guy

and part of the pylons project

that's... (inducing from github) mcdonc?

yes

I don't know if I've met him or not.

He was at the pycon sprints

yeah I'm sure you were in the room with him at some point when showing me hendrix

Gotcha. Yeah I'm sure I met him then.

So, what can hendrix offer to be as compelling as waitress to pyramid? (Or gunicorn to django)

well waitress only offers compatibility

it was built to run on py2/3 windows os x unix... basically everywhere

no other wsgi server supported that

jMyles: has hendrix added documentation showing anything other than django yet?

nope

i don't get why you keep coming here to talk about a wsgi server that only works with django

inklesspen: The only example that explicitly invokes Django is the quickstart. And yeah, I agree it makes more sense to do more than just Django. Sorry about that.

But hendrix runs pyramid wonderfully.

jMyles: can you point me to a single example on that page where you are not running a django app

(better than it does Django for at least some purposes)

it doesn't matter if it runs pyramid wonderfully if the "how to use it" docs only show django

pyramid just advocates the wsgi server that is guaranteed to work everywhere for simplicity... we have some deployment docs in our cookbook for other servers