function fields for other records in the same model. Previously all function fields in the
current model were not computed for some reason not provided by the history.
We therefore compute effective store_ids on which the various trigerred
function fields will be computed again. Those ids are the ids given
in the store_get storage variable minus the deleted ones.
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.
The active_test flag is meant for search(),
but when passed to search_read() it was also
propagated to the read() call.
This has little consequence normally because
read() ignores this flag, but it can have
side-effects when reading x2m fields or
function fields. They are likely to call
search() somewhere downstream, still with
the propagated active_test flag, while
it should not be applied anymore.
Ultimately dropping this flag could be
done by read() in all cases, but changing
search_read() is less likely to block
exotic cases where the flag was passed
on purpose. Moving it to read() could
be done as a later step.
This was problematic on some views where two views with the same priority could be chosen depending on the server, postgresql version and the age of the captain
The value_unpickled given by xml data is usualy already evaluated but when it is given by the web client, a str is recieved by the method (as the field is a text field). In the later case, we need to evaluate the field before storing to be correctly evaluated as a default value.
bzr revid: mat@openerp.com-20140509130412-ki211x7qdccdnv5w