On Wed, Jul 8, 2009 at 11:29, Erik Kay<[email protected]> wrote: > 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).
I'll go back and reread that design doc to see how that might change things. > 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 >> >> >> > > -- erik --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
