data-i18n in development

[rolandliwag]

Htmlizer templates can be used with assetgraph-builder via the data-i18n attribute and this works fine when the template is run through buildProduction. But I'd like to be able to use the templates during development as well. Any ideas?

[papandreou]

In a project I did at work I parsed, internationalized and reserialized the templates before passing them to htmlizer. I used memoization to prevent extra run time costs per rendering of a template.

(See lines 36--75 of formMail.js if you can gain access to the formmail.git repo).

[rolandliwag]

That was also the only solution I had in mind outside of Htmlizer. Did you do the parsing with jsdom? I guess it's not a big deal with this requirement only being relevant in development mode but it seemed like a lot of pushing and prodding.

[papandreou]

Yeah, jsdom. In formmail the same solution is used in production, but I could of course replace that with buildProduction-translated templates.

Since those lines of code don't really contain anything secret, I guess the easiest thing is to just quote them:

var memoizeAsync = require('memoizeasync'),
    memoizeSync = require('memoizesync'),
    pathModule = require('path'),
    fs = require('fs'),
    Htmlizer = require('htmlizer'),
    jsdom = require('jsdom'),
    i18nTools = require('assetgraph-builder/lib/i18nTools');

[...]
    var i18nKeys = JSON.parse(fs.readFileSync(i18nFile, 'utf-8')),
        getAllKeysForLocale = memoizeSync(function (localeId) {
            var allKeysForLocale = {},
                prioritizedLocaleIds = i18nTools.expandLocaleIdToPrioritizedList(localeId);
            for (var key in i18nKeys) {
                if (i18nKeys.hasOwnProperty(key)) {
                    for (var i = 0 ; i < prioritizedLocaleIds.length ; i += 1) {
                        if (prioritizedLocaleIds[i] in i18nKeys[key]) {
                            allKeysForLocale[key] = i18nKeys[key][prioritizedLocaleIds[i]];
                            break;
                        }
                    }
                }
            }
            return allKeysForLocale;
        }),
        memoizedLoadTemplate = memoizeAsync(function (templateName, cb) {
            fs.readFile(pathModule.resolve(__dirname, '..', 'templates', templateName + '.html'), 'utf-8', cb);
        }),
        memoizedGetTemplateRenderer = memoizeAsync(function getTemplateRenderer(templateName, localeId, cb) {
            memoizedLoadTemplate(templateName, passError(cb, function (templateSource) {
                var document = jsdom.jsdom(templateSource);
                i18nTools.eachI18nTagInHtmlDocument(document, i18nTools.createI18nTagReplacer({
                    allKeysForLocale: getAllKeysForLocale(localeId),
                    localeId: localeId
                }));
                var translatedTemplateSource = jsdom.serializeDocument(document);
                // Currently htmlizer throws away the <!DOCTYPE>, so we parse that separately and reattach it to the rendered HTML.
                // https://github.com/Munawwar/htmlizer/issues/10
                var doctype = '';
                translatedTemplateSource = translatedTemplateSource.replace(/^<!DOCTYPE[^>]*>\n?/, function ($0) {
                    doctype = $0;
                    return '';
                });
                var htmlizer = new Htmlizer(translatedTemplateSource);
                cb(null, function (obj) {
                    return doctype + htmlizer.toString(obj);
                });
            }));
        });

And then the request handler uses the async memoizedGetTemplateRenderer(templateName, localeId, cb) function to get a template renderer for a given template specialized for a given locale.

[papandreou]

NB: The above code uses jsdom 2.0.0. It might not work in newer versions.

[rolandliwag]

I guess unless @Munawwar indicates in any way his willingness to support this in some way in Htmlizer directly, I'll have to bite the bullet and squeeze it in.

jsdom any version shouldn't be an issue. As mentioned, I'm only interested in making it work for development mode anyway. Thanks for the help.

[Munawwar]

I'd prefer not to give special treatment for build tools (to keep Htmlizer generic). So I suggest using @papandreou's solution.

I can try and avoid having to reserialze to html though. Htmlizer constructor internally accepts DocumentFragment created from document object (which is created internally). I guess if I start accepting the document object itself, we can probably avoid reserialization (and also I can solve the doctype problem #10).

var htmlizer = new Htmlizer(document);

[papandreou]

That sounds like a great compromise!

[rolandliwag]

I like that idea. When will you be back from vacation?

[Munawwar]

@rolandliwag With v2, jsdom has been removed as dependency. So document (or any standard DOM objects) cannot be accepted now. So you'll have to continue serializing DOM to HTML string to achieve your use case.

Alternatively, if you rewrite i18nTools to use domhandler, then I could accept the tree (dom-like) structure which domhandler returns. (However for the sake of dev environment that would be an overkill).