I've just uploaded an experimental patch series to Gerrit under the
topic "webui-modernisation":
http://gerrit.beaker-project.org/#/q/topic:webui-modernisation,n,z
I have been working on it on-and-off in my spare time for a while now.
I see this as the most viable way forward for Beaker's web UI, to start
replacing some of the most problematic parts of our TG1 stack without
a wholesale rewrite.
The most interesting patches are:
http://gerrit.beaker-project.org/2086
which lets us escape from TurboGears Visit/Identity in favour of our own
simpler and more flexible implementation, and:
http://gerrit.beaker-project.org/2087
which lets us eventually replace CherryPy's object mapping and
TurboGears' @expose decorator with Flask.
The third big TurboGears pain point for us is TG widgets. Given we are
already at the point where JavaScript is required for some parts of the
web UI to work, we might as well go whole hog and embrace some of the
modern JS widget libraries or even "single-page application" frameworks.
But I am still new to this modern JS world and this patch using Backbone
is just an experiment with one possible way of doing things:
http://gerrit.beaker-project.org/2095
I wasn't particularly happy with how messy and verbose it came out. So
I'm not sure this is the final answer.
What's still missing:
* Patches to update our HTML for Bootstrap on all other pages (only the
group page is done so far). Unfortunately this really has to be done
wholesale in one go, otherwise you end up with some pages with the old
Fedora-ish style and others in the new Bootstrap style. The good news
is that there's not *too* much work involved in this, assuming that
you don't fall into the trap of trying to clean up or improve the
existing layouts or UI too much (which is a trap I had to keep myself
from continually falling into).
Some unresolved questions:
* JS libraries: Backbone seems like a good fit, but it seems very
barebones and so we would need to (re-)invent a lot of things
ourselves. There are some promising-looking extension libraries for
it, such as Epoxy.js, which might be useful. Alternatives are Ember.js
and AngularJS, but I have not experimented with those yet. In any
case, it makes sense to settle on a single preferred approach and
start working towards using that consistently and eliminating older
pieces of JS (including MochiKit).
* Building assets: right now the compiled versions of the CSS and JS are
committed to git, to avoid depending on LESS and Uglifyjs during the
build. But that will very quickly get annoying to maintain I think.
Can we reasonably pull in those tools (and the entire NodeJS
dependency chain) during the build?
--
Dan Callaghan <dcallagh(a)redhat.com>
Software Engineer, Infrastructure Engineering and Development
Red Hat, Inc.