Normal m2o values are pairs of (id, name) (name_get format, basically)
but in some cases (lazyness & al), APIs (often onchange results) only
return the `id` part, which is not sufficient to display the m2o
as-is, a name_get has to be performed.
Added an intermediate step in displaying a table cell (in list view):
if we're displaying an m2o cell (~a cell for an m2o column) and the
value is a number, then dispatch a name_get and keep trucking (display
the rows without the m2o values).
When the name_get returns, it will simply refresh the row and diplay
the m2o name.
bzr revid: xmo@openerp.com-20111014084310-pv2mmmy28fwwk9sm
Plan was originally to just ignore this because "it should just work"
but turns out m2o and m2o[@widget=selection] fields have very
different behaviors when it comes to default values, especially
custom domains and contexts:
* An m2o field uses its string value always (behaves like a char
field), for UI and clarity purposes we added an [[name, '=', id]]
case when the user specifically selects an autocompletion value,
but that's not "cannon", when it comes to dealing with custom
domains (filter_domain) and contexts the field always uses its
string value.
* An m2o[@widget=selection] field on the other hand uses its ids
always (behaves like a selection field).
That's not entirely true, really, because it has the converse to
what we implemented on the m2o field in the web client (in the GTK
client): if there is no @filter_domain *and* the user has entered a
value which is not in the dropdown (it's a combobox in the GTK
client), then it falls back on using 'ilike'. This string value is
*not* used in custom domains and custom filters, which simply are
not submitted.
This second section has *not* been implemented so far in the web
client, we'll come round to it if people actually need it.
bzr revid: xmo@openerp.com-20111006063949-fl5rbg3wwubcaay8
In some cases, at least with complex-enough views, inserting many
options in a document in a row will get progressively slower.
In import, this issue is hit on trying to import partners: partners
have a humongous number of fields (direct and on their o2m), ~940,
which yields a correspondingly huge number of options in the
selection.
A basic partner export also has quite high a number of columns (~50
without exporting o2m fields), so this list of 940 options is inserted
50 times in a row (literally too, they're all in the same table row)..
While not all that fast, Firefox 5/6 has no significant issue with
this (~18ms/insertion, where an insertion is a full select with all
its options). Webkit browsers (Chrome and Safari) on the other hand
start out fair (~10ms/insertion), but get slower and slower until they
end up at 3~5 *seconds* for each insertion (3s if inserting a
DocumentFragment, 5s if inserting text via innerHTML). This means the
preview table takes up to *two minutes* to display, even the best
cases (pre-generating everything that can be and optimizing everything
I could think of) take 75 *seconds* for the insertions (the
pregeneration of a given select and its options is ~100ms, the base
template rendering is ~20ms).
rendering divs or inputs does not have this issue, I did not manage to
reduce or fix the issue directly so I replaced the options by
jQuery-ui's autocomplete widget. This is not issues-free: when tabbing
through the fields lists, when reaching the edge of the popup the
browser will automatically scroll the field back into view. However,
this is done *after* autocomplete's popup has opened, and as a result
the popup opens in the wrong place (at the popup's edge, instead of
under the now-moved field).
bzr revid: xmo@openerp.com-20110922085812-3u1esk6czraskm01
Xavier Morel
Turkesh Patel (Open ERP)
Fabien Meghazi
Antony Lesuisse
Christophe Simonis
niv-openerp