Xavier Morel
7e1827a011
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.
Odoo
Odoo is a suite of web based open source business apps.
The main Odoo Apps include an Open Source CRM, Website Builder, eCommerce, Warehouse Management, Project Management, Billing & Accounting, Point of Sale, Human Resources, Marketing, Manufacturing, ...
Odoo Apps can be used as stand-alone applications, but they also integrate seamlessly so you get a full-featured Open Source ERP when you install several Apps.
Getting started with Odoo
For a standard installation please follow the Setup instructions from the documentation.
To learn the software, we recommend the Odoo eLearning, or Scale-up, the business game. Developers can start with the developer tutorials