A note concerning the attributes which I will probably need to take a
look at in the vdom version: the Python version has to process attf in
order to stringify individual elements, and separately stringify the
attribute value so it gets forcefully escaped even if it's
markup-safe (because markup-safety and attributes-safety are
different).
The first should not need to be performed on the JS side, because
Markup can not overload addition, therefore in JS String + Markup is
String whereas in Python it's Markup (and the String gets forcefully
escaped). In general, js!markup is currently much simpler than
py!markup, both by necessity (can't overload operators) and
simplicity (we might want to overload some of the operations
e.g. String#replace, but that's complicated and it's not been strictly
necessary for now).
Also wrt Markup / _Markup: `class` ctors can only be invoked with
`new` meaning they can't be used as template strings or regular
functions. Here `class` is useful to avoid the mess of calling the
super's constructor explicitly (which may not even be possible for
`String`), however it means we need a facade function to support our
use-cases.
Also update `utils.sprintf` to be Markup-aware: if the format string
is a Markup object, interpolated values get automatically escaped (if
necessary) and the result remains a Markup object.
If we need to perform explicit instance check we can always set
`Markup.prototype = _Markup.prototype` (I think), however in theory
that's not necessary: there are protocols in place for the relevant
pseudo-escaping operations and they ought suffice.
qweb/js divergence from qweb/py
===============================
Unlike qweb/py, qweb/js will *not* return a Markup object. That is
because in js a primitive `string` and a boxed `String` object don't
match when typechecking, and while `markup instanceof String` passes,
`typeof markup === 'string'` does not.
The overwhelming majority of string typechecks are the latter: there
are all of 6 `instanceof String` in the entire codebase, all in
dependencies, while there are hundreds of `typeof $X === 'string'`,
several of which get fed the output of template rendering
e.g. `jQuery.parseXML` or `AbstractView#init` (some widgets will
render a template then use it as the `arch` of a subview, so
`viewInfo.arch` can be the output of a qweb template rendering). This
makes for very annoying and somewhat gnarly debugging.
Plus jQuery in particular really doesn't like being fed a boxed
String, as it will interpret said boxed string as an array, and assume
it's an array of DOM elements to wrap, leading to a rather strange
jQuery object as output. Since feeding the result of a template
rendering to jQuery is a major use-case in non-vdom widgets... that's
a bit of an issue.
For the same reason while `_.escape` is `Markup`-aware, unlike
`markupsafe-escape` it does not *produce*, though it is
`Markup`-transparent.
One of the qweb tests checks that in a t-set @t-value takes priority
over body contents. However this construct also triggers a warning
when invoked.
Mock out `window.console` during qweb tests, this suppresses that
warning.
To prepare the rewriting of the webclient in owl, we move all
current js files of web in a legacy/ folder. This folder will
eventually be removed, as soon as each file it contains will be
converted to owl and moved to the proper place in the new file
structure.
Xavier Morel