This seems like a reasonable plan. It would be cool if whatever mechanism you chose could be leveraged by extensions as well (see the earlier extensions i18n proposal that was sent around last week). For this reason I'd prefer that if we moved to a C++ solution (as others in this thread have suggested) that it run in the renderer and not in the browser process (for security reasons). Erik
On Wed, Jul 8, 2009 at 11:02 AM, Erik Arvidsson <[email protected]> wrote: > > Currently we use JsTemplate > (http://code.google.com/p/google-jstemplate/) to do our l10n of the > DOMUI. JST has been working well but it is a bit of an overkill to do > l10n of our UI. It has a couple of features that makes it slow down > the UI: > > 1. It uses eval for every single RHS > 2. It uses two nested with statements > 3. It traverses the whole DOM using JavaScript > > It also has some advanced features like jsselect, which allows > iteration, that we are using for non l10n things. > > My plan is to create a simpler solution, with almost exactly the same > syntax that solves the 3 bullet points above. It will not allow > arbitrary expressions on the RHS and it will only support jsvalues and > jscontent. Instead of traversing the entire tree it ill use > document.querySelector which does the tree traversal in C++ and uses > CSS selectors as the matching which is a lot faster than doing the > tree traversal in JS. > > Since there are still cases where we use JST to do more advanced > templating it will still be available but it will require opt in. > > Any thoughts? > > -- > erik > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
