Order of evaluation in view inheritance

As we have only one parent view and one inheriting view currently, we don't run into any problems with conflicting view overrides. When you have installed a couple of modules, you'll find a lot of overrides for the partner form. This is all fine as long as they change different things in a view, but there are occasions where it is important to understand how overriding works in order to avoid conflicts. Direct descendants of a view are evaluated in ascending order of their priority field, so views with a lower priority are applied first. Every step of inheritance is applied to the result of the first, so if a view with priority 3 changes a field and another one with priority 5 removes it, things are fine, but they break if the priorities are reversed.

Then, you can also inherit from a view that is an inheriting view itself. In this case, the second level inheriting view is applied to the result of the view it inherits from. So, if you have four views, A, B, C, and D, where A is a standalone form, B and C inherit from A, and D inherits from B, the order of evaluation is A, B, D, C. Use this to enforce an order without having to rely on priorities; that's safer in general. Especially, if some inheriting view adds a field and you need to apply changes to this field, inherit from the inheriting view and not from the standalone one.

This kind of inheritance always works on the complete XML tree from the original view, with modifications from the previous inheriting views applied.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.128.78.30