Before this commit, @mode=primary would be sorta-ignored[0] if the current
view and its parent had the same model: the current view would *still* get
applied (as an extension) when asking OpenERP for its parent. This commit
makes mode=primary views behave regularly, they are *never* applied when
asking for their parent, only when asking for them or their children.
This allows "forking" views, and using extended views in some contexts without
breaking or duplicating the original view
[0] there was actually a problem when asking for the current view directly,
first its parent would be resolved by applying it, then it would be
applied to resolve itself, the view would thus get applied twice (oops)
Not used yet, only defined its relation to inherit_id:
not inherit_id + primary -> ok
not inherit_id + extension -> error
inherit_id + primary -> ok
inherit_id + extension -> ok
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.
main problem, view inheritance model field would use model from the
root view (after following inherit_id links) rather than the base view
(the requested one) -> with divergent models, it was possible for the
requested view itself to never be returned.
bzr revid: xmo@openerp.com-20131212134422-uxg6h21w1jhth9ow
weird tests (using broken views, but not just broken in the way the
test expects) were really testing for error on using a field which
does not exist, predicated on full rendering of the view during
validation.
This has been removed from the website branch as it's unfeasible and
nonsensical for model-less views (e.g. qweb), and thus the test blew
up with a completely different error (missing @string) or, once the
test was fixed, wouldn't blow up at all.
bzr revid: xmo@openerp.com-20131211162412-t31bxkpy2yzdnf0q
expectation of view validation errors when creating view referencing
non-existent fields or models, but in website branch models and views
have become independents, these are not context-free errors anymore.
Also fix shit code.
bzr revid: xmo@openerp.com-20131007093328-gjrktqbsoe48ikol
When a new inheriting view is imported during a module
installation, it is validated thanks to the _constraints
on the ir.ui.view model. However the validation uses
a rather convoluted system for validating the whole
view tree at once (root view + all inherited changes)
while only taking into account the views that belong
to modules that are currently loaded.
This complicated system is necessary to be able to
operate on-the-fly at any point during the registry
loading/initialization.
Now because _constraints are checked during create()
this particular validation happens *before* the
external ID (ir.model.data entry) of that new view
can be created (it obviously needs to wait until
the view record is inserted). As a consequence the
view validation cannot determine the module to
which that new view belongs, and was erroneously
ignoring it.
Changing the view filtering to also include views
that have triggered this check.
Manually created views are not check during registry
update.
bzr revid: chs@openerp.com-20130912141018-qmcyase8zqov9d01
A view for a given model can inherit from a root view specified for
another model. When applying the modifying views to the root view,
only the views with the same model as the child view must be
considered. This patch restore that behavior.
bzr revid: vmt@openerp.com-20130701145334-ojp1plqjveym7cj7
* Formally make model not required
* Remove idiotic default values on type and arch
* Make type not required (it's a function field!)
bzr revid: xmo@openerp.com-20130426145113-cf0t0xx24lk9mtgs