Not the working solution, but getting there conceptually. Basically
we'll have a key with the view and the template as a tuple which is
the context hook that anyone can attach to.
However, some changes have still to be made:
- The unit test doesn't work yet and contains a set_trace ;)
- We'll probably switch the "view" component from being the callable
to the "urlgen"'able name per Elrond's suggestion
- Found a bug in unit tests related to running custom apps for
different configs... hm. I need to fix this!
Nonetheless, making progress.
This commit sponsored by... wait a minute... Christopher Webber?!
1. Our session cookies only need to be available to http, so
mark them appropiately.
2. Send the cookie to the subpath for mediagoblin.
And instantiate a session manager on the app, once.
The move to werkzeug routing went pretty smooth, but one thing was
broken by accident: URLs without final slash result in a 301
werkzeug.routing.RequestRedirect response. We displayed it as a generic
error page rather than actually sending the redirect. Do that. One thing
it does though is to skip all meddlewares, which should be OK for a 301
response, but might need rework if we decide otherwise. With this, 301
responses with lacking final slash are unbroken again.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Since sqlalchemy is providing our database abstraction and we have
moved away from Mongo as the underlying database, it is now time to
simplify things and rip out mongo. This provides the bulk of the
changes, and can stand on its own. There are some followup tasks
that can be done, such as removing now unneeded abstraction layers,
e.g. db.sql.fake.py
MGRoute subclasses Rule():
Rule doesn't have a way to tag extra data, like the
controller function, we need. So MGRoute has a new
attribute .gmg_controller, which holds this.
Rewrite everything to use this new Rule variant and drop
all the other stuff that mapped endpoints to controller
functions, mostly.
After the webob->werkzeug transition, controller functions can raise
werkzeug.HttpExceptions. We need to catch these in app.py when calling
the controller and handle them, rendering the corresponding error Response()
object. For consistency, we also want to allow meddleware functions to
raise HttpExceptions (e.g. the csrf meddleware needs to complain about lack
of cookies), so wrap the request and response parts of the meddleware too.
Finally, the urlmap.match() can also raise HttpExceptions, so we give it the
same treatment (render_http_exception). I am not sure, if we do not need to
handle the Redirect exception there in any different way though...
The new function render_http_exception makes use of the render_error infrastructure
to return a nicely templated error page. It also checks if the stock error
messages was used in cases where we have localizations (403, 404) and use those.
It is now possible to do things like "raise Forbidden(_('You suckr'))" or
raise NotFound(_('where is my left show again')) if you want to return
customized error messages to the user.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
It is killing testsuite output by drowning out all signals. It should
be sufficient to state in the pluginmanager that routes have been added,
if we need that kind of output.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Remove the aliases we provided for webob compatability as webob is
now gone. Grepped the code base to check for occurences of the old
parameters to be safe. Keep request.GET attribute as alias for
request.args as it is often used and django is also using that
attribute.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We were still using webob's Response objects for template rendering.
Transition to werkzeug's Response object. One caveat was that it
seemed to have used the default mimetype "text/plain" for all pages,
so we override the default Response class, setting the default mime
type to "text/html".
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Previously we would attempt to satisfy the user's first language
preference, immediately falling back to english if that was not
possible. Now, we will get the best match of the user's preferred
languages.
This requires storing the available locales on app startup, so we
have mg_globals.available_locales ready to compare them against the
list of preferred user languages.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We only ever served english pages since the switch to werkzeug's requests.
Fix this by actually checking the accepted languages that our web browser
sends and using that or falling back to english.
This is not optimal, imaging our browser sends "klingon, de" as accepted
languages and we happen to not have a klingon translation ready (a deficiency
that should be corrected immediately anyway!!). We would then fall back
to english rather than sending the sensible and pleasant German language
which the user would understand. This will require more backend work though.
Removing the gettext.find() in mg_globals.py. It looked in the wrong directory
anyway (mediagoblin/translations) and as that does not exist, had always returned
None without anyone noticing.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Removed the Routes routing functionality and replaced it with
werkzeug.routes. Most views are functional.
Known issues:
- Translation integration with the request object is not yet figured
out. This breaks 404 pages.
This reworks the plugin infrastructure so as to remove module-loading
side-effects which were making things a pain in the ass to test.
With the new system, there's no auto-registering meta class. Instead
plugins do whatever they want and then specify a hooks dict that maps
hook names to callables for the things they're tying into. The most
common one (and the only one we've implemented so far) is "setup".
This also simplifies the sampleplugin a little by moving the code
to __init__.py.
This fixes the template loader so that it can load plugin templates.
This adds code for registering template paths so that plugins can add
their own templates.
This adds the base code for the flatpagesfile plugin. It doesn't serve
pages, yet, but it's pretty close.
The cleanup could be missed if the request handling code in
app.py:__call__ exits early (due to exception, or due to
one of those early "return"s).
So to make sure the sql session is cleaned up for real,
wrap the whole thing in a try: finally:.
Also wrote a short tool to test if the session is actually
empty. The tool is currently disabled, but ready to be
used.
It's good practice to cleanup the SQL session after each
request so that the next request gets a fresh one.
It's an application decision whether one wants a
just-in-case ROLLBACK or COMMIT. There are two ideas behind
it, really. I have decided for ROLLBACK. The idea is "if
you forget to commit your changes yourself, there's
something broken. Maybe you got an exception?".
There was no place in the software telling the user the
version in use. So start by having the main server emit a
startup notice including the version string. Uses python
logging, so should be easy to reconfigure, etc.
This is relevant for fcgi:
Some servers (cherokee for example) put "HTTP":"off" in the
environ. And the following code in urlgen breaks on this:
if environ.get('HTTPS') or environ.get('wsgi.url_scheme') == 'https' \
or environ.get('HTTP_X_FORWARDED_PROTO') == 'https':
hostinfo['protocol'] = 'https'
workaround is to remove HTTPS:off from the environ.
