a little wsgi framework

[timmyt]

On Jul 7, 5:19 am, Bruno Desthuilliers <bruno.
42.desthuilli... at websiteburo.invalid> wrote:
> timmyt a écrit :
>
> > i'm interested in getting opinions on a smallwsgiframework i
> > assembled from webob, sqlalchemy, genshi, and various code fragments i
> > found on the inter-tubes
>
> > here is the interesting glue - any comments / suggestions would be
> > much appreciated
>
> <meta>
> Well... My first comment would be about the usefulness of yet another
> Python web framework, but let's not worry about this...
> </meta>
>
> > ------------------
> > thewsgiapp
> > ------------------
> > def application(environ, start_response):
> >     path = environ.get('PATH_INFO', '').lstrip('/')
>
> >     for regex, callback in urls:
> >         match = re.search(regex, path)
>
> I don't know where these "urls" come from. But anyway : if they live in
> some sort of long-running process, you may want to precompile them.
>
> >         if match:
> >             environ['myapp.url_args'] = match.groups()
> >             request = webob.Request(environ)
>
> >             try:
> >                 return callback(request, start_response)
> >             except Exception, ex:
>
> How are redirect etc handled ?
>
> >                 start_response('500 Internal Server Error', [('Content-
> > Type', 'text/plain')])
> >                 return [traceback.format_exc()]
>
> A configuration option controlling the display of the traceback would be
> fine - I surely don't want the traceback being displayed to anyone when
>   the app goes into production.
>
> Also, logging the error and traceback might be useful.
>
> >     start_response('404 Not Found', [('Content-Type', 'text/plain')])
> >     return ["Couldn't find the URL specified."]
>
> And in both cases, having the ability to use "custom" 500 and 404 pages
> might be nice too.
>
>
>
> > ----------------------------------
> > the controller decorator
> > ----------------------------------
> > def web_decorator(filename, method='html'):
>
> >     def decorator(target):
>
> May I suggest some renaming here ?
>
> filename => path (or 'template_path' ?)
> method   => content_type
> target   => controller or function or callback or....
>
> >         def wrapper(request, start_response):
>
> >             #genshi TemplateLoader
> >             template = loader.load(filename)
>
> >             global config
>
> Probably not thread-safe....
>
> >             try:
> >                 return_dict = target(request, start_response)
> >                 return_string = template.generate(**return_dict).render
> > (method)
>
> Renaming again:
> return_dict => context
> return_string => data or text or ???
>
> >                 config['database.Session'].commit()
> >             except:
> >                 config['database.Session'].rollback()
> >                 raise
> >             finally:
> >                 config['database.Session'].remove()
>
> This doesn't leave much control on transactions... Sometimes you want to
> handle it manually one way or another.
>
> >             #TODO: alter 'Content-Type' per method being passed
> >             start_response('200 OK', [('Content-Type', 'text/html')])
> >             return [return_string]
>
> Ok, so here again, I don't understand how redirects can work. Also, if
> you do use start_response here, I don't get why you still pass it to the
> callback function.
>
> >         return wrapper
>
> >     return decorator
>
> slightly OT, but preserving infos on the decorated function might help
> too (introspection, debugging etc).
>
> My 2 cents...

thank you gentlemen

i'm now looking for Redirect exceptions as well, and returning the
appropriate response code (stole this idea from turbogears)

i like doing the response codes and exceptions myself which is why i'm
not using the webob response - i think it's more explicit and
straightforward

the conditional display of errors goes without say - that will be
trivial to add

the 'global config' line was an error - config is a module level
variable set before the application definition

i assume as long as i don't write to the config variable within the
application it is thread-safe - is that correct

the underlying assumption is the wsgi application setup does not have
to be thread safe - this is only run once per process