The idea is to have a class that has the knowledge of the
currently being processed media and also has tools for
that.
The long term idea is to make reprocessing easier by for
example hiding the way the original comes into the
processing code.
We missed to search for translatable strings in our plugins
and other things that might have templates.
The search is now for **/templates/**.html. That should
catch a lot more.
The template in the geolocation plugin still used the old
config option. Just remove that. To enable it, you enable
the plugin. No need for extra config.
Tested by manwesulimo2004 (via IRC).
For all our media_types, let the backref on the media_entry
be a scalar (there is only one media_data per media_entry)
instead of a list with zero or one entry.
The media_data toolchain on MediaEntry currently handles
both transparently.
Instead of doing query by hand, use the relationships on
the models to find the media_data. Is is made possible by
the BACKREF_NAME in each models.py, which lets us know the
local attr to ask for.
Also initialize the relationship attribute on new
media_data instead of the media_id. Also do not add it to
the session. This gives us:
- This automatically initializes the other side of the
relationship, which will allow later acces via that way.
- If the media_data is too early in the session, when the
(new) media_entry is not yet in there, this could get
conflicts. Avoid those by not adding to session.
- Uses cascading to commit media_data together with the
media_entry.
- I'm having trouble seeing if the geolocation stuff actually works,
but plugins are included
- including a list of template hooks works, however the macro to
include them does not, so it's kinda verbose
- Added start of template hook code to pluginapi.py
- Started to break openstreetmap into plugin; moved templates
- Added plugin hooks in media and image media templates
... almost certainly, none of this works yet. :)
py3 does not have dict.has_key any more. You have to use
"key in dict" instead. As that works in python2 as well,
let's use that.
Also some small bits of pep8.
This currently fails (with foreign key constrain error):
1. Have user A and B.
2. User B creates media M.
3. User A post a comment on M.
4. User A deletes his own account.
The test is a little bit wider.
We need some "Part" for developers. Currently, it's named
"Part 4: Developer's Zone". But we should come up with a
better name soon.
Moved the codebase docs in there for starters.
Allow us to extract docstrings from our sources using the
sphinx.ext.autodoc module.
First use: Extract some of the docs for the pluginapi and
provide it in a new "Plugin API" section.
