I have a problem with repeated code in the routes of our pyramid app. I'm pretty sure I'm doing it wrong, but don't know how to do better. Our app essentially has three "modes" which are represented as prefixes to the URL path. With no prefix, we're in "prod" mode, then we have "/mock" and "/old" prefixes which use the same views with different backends to fetch the data.
The code turns out looking like this:
def routes(config):
"""Add routes to the configuration."""
config.add_route('my_view:old', '/old/my_view')
config.add_route('my_view:prod', '/my_view')
config.add_route('my_view:mock', '/mock/my_view')
#view_config(route_name='my_view:mock', renderer='string')
def my_view_mock(request):
return my_view(request, data.mock)
#view_config(route_name='my_view:prod', renderer='string')
def my_view_prod(request):
return my_view(request, data.prod)
#view_config(route_name='my_view:old', renderer='string')
def my_view_old(request):
return my_view(request, data.old)
def my_view(request, data):
results = data.query(**request.json)
What's worse, is this pattern is repeated for all of our endpoints, resulting in a ton of nearly-duplicate boilerplate code.
How can I teach pyramid about my setup in some centralized manner and get rid of this boilerplate?
Well here's an option. It requires you to define a unique object for each view. The nice part is that you can define that object and then each route can create it differently ... imagine factory=lambda request: MyView(request, old=True) instead of using the exact same MyView(request) object for each route.
def routes(config):
"""Add routes to the configuration."""
config.add_directive('add_routed_resource', add_routed_resource)
config.add_routed_resource('my_view', MyView)
def add_routed_resource(config, name, factory):
routes = [
('%s:old', '/old/%s-errors', lambda request: factory(request, old=True)),
('%s:prod', '/%s', factory),
('%s:mock', '/mock/%s', lambda request: factory(request, mock=True)),
]
for name_fmt, pattern_fmt in routes:
config.add_route(
name_fmt % name,
pattern_fmt % name,
factory=factory,
use_global_views=True,
)
class MyView:
def __init__(self, request, old=False, mock=False):
self.request = request
self.old = old
self.mock = mock
#reify
def data(self):
# let's assume sqlalchemy query to load the data?
q = self.request.db.query(...)
if self.old:
q = q.filter_by(old=True)
return q.one()
#view_config(context=MyView, renderer='json')
def my_view(context, request):
return context.data
Related
Is there a way to get query string as function parameters on flask?
For example, the request will be like this.
http://localhost:5000/user?age=15&gender=Male
And hope the code similar to this.
#app.route("/user")
def getUser(age, gender):
...
If you are willing to write a decorator, anything is possible:
from functools import wraps
def extract_args(*names, **names_and_processors):
user_args = ([{"key": name} for name in names] +
[{"key": key, "type": processor}
for (key, processor) in names_and_processors.items()])
def decorator(f):
#wraps(f)
def wrapper(*args, **kwargs):
final_args, final_kwargs = args_from_request(user_args, args, kwargs)
return f(*final_args, **final_kwargs)
return wrapper
return decorator if len(names) < 1 or not callable(names[0]) else decorator(names[0])
def args_from_request(to_extract, provided_args, provided_kwargs):
# Ignoring provided_* here - ideally, you'd merge them
# in whatever way makes the most sense for your application
results = {}
for arg in to_extract:
result[arg["key"]] = request.args.get(**arg)
return provided_args, results
Usage:
#app.route("/somewhere")
#extract_args("gender", age=int)
def somewhere(gender, age):
return jsonify(gender=gender, age=age)
Flask views themselves do not have obligatory args. You can write:
from flask import request
#app.route("/user")
def getUser():
age = request.args.get('age')
gender = request.args.get('gender')
You can do this by getting Flask-Publisher and adding "#publish()" decorator before your getUser function:
from publisher import publish
#app.route("/user")
#publish()
def getUser(age:int, gender):
...
This uses inspection to get the arguments, optionally uses type annotations to convert the incoming arguments, and pulls the values from the GET/POST data.
Just starting off with Flask, following along at http://flask.pocoo.org/docs/views/
Say I have a basic REST api, in this case for symptoms:
/
GET - list
POST - create
/<symptomid>
GET - detail
PUT - replace
PATCH - patch
DELETE - delete
I can implement this pretty cleanly with Flask's MethodView as follows:
from flask import Blueprint, request, g
from flask.views import MethodView
#...
mod = Blueprint('api', __name__, url_prefix='/api')
class SymptomAPI(MethodView):
""" ... """
url = "/symptoms/"
def get(self, uid):
if uid is None:
return self.list()
else:
return self.detail(uid)
def list(self):
# ...
def post(self):
# ...
def detail(self, uid):
# ...
def put(self, uid):
# ...
def patch(self, uid):
# ...
def delete(self, uid):
# ...
#classmethod
def register(cls, mod):
symfunc = cls.as_view("symptom_api")
mod.add_url_rule(cls.url, defaults={"uid": None}, view_func=symfunc,
methods=["GET"])
mod.add_url_rule(cls.url, view_func=symfunc, methods=["POST"])
mod.add_url_rule('%s<int:uid>' % cls.url, view_func=symfunc,
methods=['GET', 'PUT', 'PATCH', 'DELETE'])
SymptomAPI.register(mod)
But, let's say I would like to attach another api on these individual symptoms:
/<symptomid>/diagnoses/
GET - list diags for symptom
POST - {id: diagid} - create relation with diagnosis
/<symptomid>/diagnoses/<diagnosisid>
GET - probability symptom given diag
PUT - update probability of symptom given diag
DELETE - remove diag - symptom relation
I would then have 4 GETs instead of two as above.
Do you think this a bad api design?
Would MethodView be appropriate for this design? (if the design is not bad)
How would you implement these routes?
So ... in writing this question, I have found a decent solution. As long as I'm here, I might as well post the question and the solution I have. Any feedback would still be greatly appreciated.
I think the design is ok. MethodView should be pretty awesome for it. You can put the routes together like so:
class SymptomDiagnosisAPI(MethodView):
"""
/<symptom_id>/diagnoses/
GET - list diags for symptoms
POST - {id: diagid} - create relation with diagnosis
/<symptom_id>/diagnoses/<diagnosis_id>
GET - probability symptom given diag
PUT - update probability of symptom given diag
DELETE - remove diag - symptom relation
"""
def get(self, symptom_id, diagnosis_id):
if diagnosis_id is None:
return self.list_diagnoses(symptom_id)
else:
return self.symptom_diagnosis_detail(symptom_id, diagnosis_id)
def list_diagnoses(self, symptom_id):
# ...
def post(self, symptom_id):
# ...
def symptom_diagnosis_detail(self, symptom_id, diagnosis_id):
# ...
def put(self, symptom_id, diagnosis_id):
# ...
def delete(self, symptom_id, diagnosis_id):
# ...
#classmethod
def register(cls, mod):
url = "/symptoms/<int:symptom_id>/diagnoses/"
f = cls.as_view("symptom_diagnosis_api")
mod.add_url_rule(url, view_func=f, methods=["GET"],
defaults={"diagnosis_id": None})
mod.add_url_rule(url, view_func=f, methods=["POST"])
mod.add_url_rule('%s<int:diagnosis_id>' % url, view_func=f,
methods=['GET', 'PUT', 'DELETE'])
SymptomDiagnosisAPI.register(mod)
I have built an application that has a lot of similar views that should be able to use the same base code. However each method has certain unique characteristics at various inflection points within the methods such that I can't figure out a way to structure this to actually reuse any code. Instead I've created a cut-and-paste methodology and tweaked each method individually. This part of the application was some of the first Python code I ever wrote and know there must be a better way to do this, but I got locked into doing it this way and "it works" so I can't see a way out.
Here's what the base view template essentially looks like:
def view_entity(request, entity_id=None):
if request.method == 'POST':
return _post_entity(request, entity_id)
else:
return _get_entity(request, entity_id)
def _get_entity(request, entity_id):
data = _process_entity(request, entity_id)
if 'redirect' in data:
return data['redirect']
else:
return _render_entity(request, data['form'])
def _post_entity(request, entity_id):
data = _process_entity(request, entity_id)
if 'redirect' in data:
return data['redirect']
elif data['form'].is_valid():
# custom post processing here
instance = data['form'].save()
return HttpResponseRedirect(reverse('entity', args=[instance.id]))
else:
return _render_entity(request, data['form'])
def _process_entity(request, entity_id):
data = {}
if entity_id != 'new': # READ/UPDATE
# sometimes there's custom code to retrieve the entity
e = entity_id and get_object_or_404(Entity.objects, pk=entity_id)
# sometimes there's custom code here that deauthorizes e
# sometimes extra values are added to data here (e.g. parent entity)
if e:
if request.method == 'POST':
data['form'] = EntityForm(request.POST, instance=e)
# sometimes there's a conditional here for CustomEntityForm
else:
data['form'] = EntityForm(instance=e)
else: # user not authorized for this entity
return {'redirect': HttpResponseRedirect(reverse('home'))}
# sometimes there's custom code here for certain entity types
else: # CREATE
if request.method == 'POST':
data['form'] = EntityForm(request.POST)
else:
data['form'] = EntityForm()
# sometimes extra key/values are added to data here
return data
I didn't even include all the possible variations, but as you can see, the _process_entity method requires a lot of individual customization based upon the type of entity being processed. This is the primary reason I can't figure out a DRY way to handle this.
Any help is appreciated, thanks!
Use class based views. You can use inheritance and other features from classes to make your views more reusable. You can also use built-in generic views for simplifying some of the basic tasks.
Check class-based views documentation. You can also read this this
So I did end up refactoring the code into a base class that all my views inherit from. I didn't end up refactoring into multiple views (yet), but instead solved the problem of having custom processing methods by inserting hooks within the processing method.
Here's the gist of the base class that inherits from DetailView:
class MyDetailView(DetailView):
context = {}
def get(self, request, *args, **kwargs):
self._process(request, *args, **kwargs)
if 'redirect' in self.context:
return HttpResponseRedirect(self.context['redirect'])
else:
return self._render(request, *args, **kwargs)
def post(self, request, *args, **kwargs):
self._process(request, *args, **kwargs)
if 'redirect' in self.context:
return HttpResponseRedirect(self.context['redirect'])
elif self.context['form'].is_valid():
self._get_hook('_pre_save')(request, *args, **kwargs)
return self._save(request, *args, **kwargs)
else:
return self._render(request, *args, **kwargs)
def _process(self, request, *args, **kwargs):
form = getattr(app.forms, '%sForm' % self.model.__name__)
if kwargs['pk'] != 'new': # READ/UPDATE
self.object = self.get_object(request, *args, **kwargs)
self._get_hook('_auth')(request, *args, **kwargs)
if not self.object: # user not authorized for this entity
return {'redirect': reverse(
'%s_list' % self.model.__name__.lower())}
self.context['form'] = form(
data=request.POST if request.method == 'POST' else None,
instance=self.object if hasattr(self, 'object') else None)
self._get_hook('_post_process')(request, *args, **kwargs)
def _get_hook(self, hook_name):
try:
return getattr(self, '%s_hook' % hook_name)
except AttributeError, e:
def noop(*args, **kwargs):
pass
return noop
The key part to note is the _get_hook method and the places within the other methods that I use it. That way, in some complex view I can inject custom code like this:
class ComplexDetailView(MyDetailView):
def _post_process_hook(self, request, *args, **kwargs):
# here I can add stuff to self.context using
# self.model, self.object, request.POST or whatever
This keeps my custom views small since they inherit the bulk of the functionality but I can add whatever tweaks are necessary for that specific view.
i'd like to use cherrypy but i don't want to use the normal dispatcher, i'd like to have a function that catch all the requests and then perform my code. I think that i have to implement my own dispatcher but i can't find any valid example. Can you help me by posting some code or link ?
Thanks
make a default function:
import cherrypy
class server(object):
#cherrypy.expose
def default(self,*args,**kwargs):
return "It works!"
cherrypy.quickstart(server())
What you ask can be done with routes and defining a custom dispatcher
http://tools.cherrypy.org/wiki/RoutesUrlGeneration
Something like the following. Note the class instantiation assigned to a variable that is used as the controller for all routes, otherwise you will get multiple instances of your class. This differs from the example in the link, but I think is more what you want.
class Root:
def index(self):
<cherrpy stuff>
return some_variable
dispatcher = None
root = Root()
def setup_routes():
d = cherrypy.dispatch.RoutesDispatcher()
d.connect('blog', 'myblog/:entry_id/:action', controller=root)
d.connect('main', ':action', controller=root)
dispatcher = d
return dispatcher
conf = {'/': {'request.dispatch': setup_routes()}}
Hope that helps : )
Here's a quick example for CherryPy 3.2:
from cherrypy._cpdispatch import LateParamPageHandler
class SingletonDispatcher(object):
def __init__(self, func):
self.func = func
def set_config(self, path_info):
# Get config for the root object/path.
request = cherrypy.serving.request
request.config = base = cherrypy.config.copy()
curpath = ""
def merge(nodeconf):
if 'tools.staticdir.dir' in nodeconf:
nodeconf['tools.staticdir.section'] = curpath or "/"
base.update(nodeconf)
# Mix in values from app.config.
app = request.app
if "/" in app.config:
merge(app.config["/"])
for segment in path_info.split("/")[:-1]:
curpath = "/".join((curpath, segment))
if curpath in app.config:
merge(app.config[curpath])
def __call__(self, path_info):
"""Set handler and config for the current request."""
self.set_config(path_info)
# Decode any leftover %2F in the virtual_path atoms.
vpath = [x.replace("%2F", "/") for x in path_info.split("/") if x]
cherrypy.request.handler = LateParamPageHandler(self.func, *vpath)
Then just set it in config for the paths you intend:
[/single]
request.dispatch = myapp.SingletonDispatcher(myapp.dispatch_func)
...where "dispatch_func" is your "function that catches all the requests". It will be passed any path segments as positional arguments, and any querystring as keyword arguments.
I have the following:
My webserver running on twisted
My comet server, aka orbited
Note that 1 and 2 are different processes.
Basically, I want 1 and 2 to share the same port. Request that are http://mysite.com/a/b/c should go to the webserver and anything starting with http://mysite.com/orbited/ should go to the orbited server, i.e. (http://mysite.com/orbited/a/b/c => do a request to http://mysite.com:12345/a/b/c and return that).
This is what I have right now:
# Reverse Proxy
class OrbitedResource(Resource):
isLeaf = True
def __init__(self, orbited_url='http://127.0.0.1:12345'):
self.orbited = orbited_url
Resource.__init__(self)
def render_GET(self, request):
def callback(html):
request.write(html)
request.finish()
def errback(failure, *args):
request.setResponseCode(http.INTERNAL_SERVER_ERROR)
request.write(failure.getErrorMessage())
request.finish()
request.setHeader('Connection', 'close')
# TODO find cleaner way to do this:
# Currently request.uri is "/orbited/....", you must trim it
target_uri = request.uri.replace('/orbited', '')
final_uri = self.orbited + target_uri
print "final_uri is", final_uri
deferred = getPage(final_uri)
deferred.addCallbacks(callback, errback)
return server.NOT_DONE_YET
class SimpleRoutingResource(Resource):
isLeaf = False
def __init__(self, wsgiApp):
Resource.__init__(self)
self.WSGIApp = wsgiApp
self.orbitedResource = OrbitedResource()
def getChild(self, name, request):
if name == "orbited":
request.prepath.pop()
print "Simple request.path is", request.path
return self.orbitedResource
else:
request.prepath.pop()
request.postpath.insert(0,name)
return self.WSGIApp
# Attaching proxy + django
log_dir = './.log'
if not os.path.exists(log_dir):
os.makedirs(log_dir)
reactor.listenTCP(DJANGO_PORT, server.Site(SimpleRoutingResource(WSGIRoot),
logPath=os.path.join(log_dir, '.django.log')))
Currently this works . However, I see that there's a class called ReverseProxyProtocol, and I have been doing tried it with the following modification:
class SimpleRoutingResource(Resource):
isLeaf = False
def __init__(self, wsgiApp):
Resource.__init__(self)
self.WSGIApp = wsgiApp
def getChild(self, name, request):
if name == "orbited":
request.prepath.pop()
print "Simple request.path is", request.path, name
return ReverseProxyResource( 'http://localhost', 12345, name )
else:
request.prepath.pop()
request.postpath.insert(0,name)
return self.WSGIApp
This is NOT Working. I have inserted a lot of prints into the twisted's reverseProxyResource class, and I discovered the following:
Given http://mysite.com/orbited/a/b/c
OrbitedResource will keep calling ReverseProxyResource with getChild until c
by the time you get to c, the url is messed up and the client class calling the orbited server will be wrong
I tried setting isLeaf = True in the ReverseProxyResource, but to no avail.
Anybody can point me a more effecient way to write the getPage? Do I really need to use ReverseProxyResource if it's such a black box in nature?
The cleanest way is to put something like nginx in front of both servers.