Server-side, view extension is done via xpath. This includes "template" views
full of HTML.
HTML elements often have a bunch of classes, sometimes even semantic
(!). XPath is generally great, but specifically lousy at dealing with
space-separated values: in standard XPath 1.0 to know if an element has a
class 'foo' the predicate is:
contains(concat(' ', normalize-space(@class), ' '), ' foo ')
and this has to be fully duplicated if there's a second class involved.
Things are slightly better with EXSLT/XPath 2.0 and tokenize, but still not
great:
tokenize(@class, '\s+') = 'foo'
and the equality check is very weird when unaware of XPath's evaluation rules.
``hasclass`` makes this much simpler to deal with: to get any ``foo`` node
with the class ``bar`` is as simple as:
//foo[hasclass('bar')
and it can take multiple class, as with e.g. jquery it will return elements
with all specified classes.
Beware though, the predicate function will be called once for each element to
check, since it's implemented in pure python and not profiled elements should
be filtered as much as possible before this point.
blocked at introducing qweb template, ir.qweb lives in the registry but nodb -> no database
with --db-filter there's a database in the session (kinda) but need to fetch it and manually get the corresponding registry...
After further considering PR #21's arguments, the setup script should
not go around setting `color.ui`:
* it shouldn't be needed for recent gits with default compile
settings[0]
* it may override advanced users's own colour configuration/
customisations (or disabling)
* it forces default colours on users for which it may be useless
(colour- blind) or even detrimental (other vision impairments)
* some linux distributions apparently default to idiotic pagers which
can't handle ANSI colour codes by default and spew garbage to the
terminal
[0] https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.4.txt#L178-L180