Setup a python virtualenv:
$ sudo yum install python-virtualenvwrapper $ mkvirtualenv hubs
Install the dependencies from PyPI:
$ pip install -r requirements.txt
Try running it with:
$ PYTHONPATH=. python populate.py # To create the db $ PYTHONPATH=. python hubs/app.py # To run the dev server
And then navigate to http://localhost:5000/designteam
There's no authn or user information at all currently. There are only:
How things are currently (they don't have to stay this way):
You write a new widget in the hubs/widgets/
directory and must declare it
in the registry dict in hubs/widgets/__init__.py
.
In order to be valid, a widget must have:
data(request, session, widgets, **kwargs)
function that returns a
jsonifiable dict of data. This will get cached -- more on that later.template
object that is a jinja2 template for that widget.chrome
decorator.This isn't implemented yet, but they're going to need:
invalidate(session, message)
function that will be used to
potentially invalidate the widget's cache. That function will get called by
a backend daemon listening for fedmsg messages so when you update your group
memberships in FAS, a fedmsg message hits the fedora-hubs backend and it
nukes/refreshes a lookup value in memcached (or some other store).Furthermore:
The template per-widget is currently held and rendered server-side with jinja2. This is how all our apps do it, more or less.
We might want to consider using handlebars.js for our templates instead and rendering all of the widgets asynchronously on the client. It could be cool, but is new-ground for our team.