1 Notes on the usage of the Form View as a sub-widget
2 ===================================================
7 * ``initial_mode`` *option* defines the starting mode of the form
8 view, one of ``view`` and ``edit`` (?). Default value is ``view``
11 * ``embedded_view`` *attribute* has to be set separately when
12 providing a view directly, no option available for that usage.
14 * View arch **must** contain node with
15 ``@class="oe_form_container"``, otherwise everything will break
18 * Root element of view arch not being ``form`` may or may not work
21 * Freeform views => ``@version="7.0"``
23 * Form is not entirely loaded (some widgets may not appear) unless
24 ``on_record_loaded`` is called (or ``do_show``, which itself calls
25 ``on_record_loaded``).
27 * "Empty" form => ``on_button_new`` (...), or manually call
28 ``default_get`` + ``on_record_loaded``
30 * Form fields default to width: 100%, padding, !important margin, can
31 be reached via ``.oe_form_field``
33 * Form *will* render buttons and a pager, offers options to locate
34 both outside of form itself (``$buttons`` and ``$pager``), providing
35 empty jquery objects (``$()``) seems to stop displaying both but not
36 sure if there are deleterious side-effects.
40 * Pass in ``$(document.createDocumentFragment)`` to ensure it's a
41 DOM-compatible tree completely outside of the actual DOM.
45 * readonly fields probably don't have a background, beware if need of
48 * What is the difference between ``readonly`` and
49 ``effective_readonly``?
51 * No facilities for DOM events handling/delegations e.g. handling
52 keyup/keydown/keypress from a form fields into the form's user.
54 * Also no way to reverse from a DOM node (e.g. DOMEvent#target) back to a
55 form view field easily