Custom build (dojo 1.7.2) and nls files.

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Custom build (dojo 1.7.2) and nls files.

nicolasenz
Hi,

I use to make custom dojo build with dojo 1.6 without problems, but since I'm trying with dojo 1.7.2, it seems nls files aren't compiled together anymore and widgets request for separated nls files. Is this a normal evolution of dojo build system or did I do something wrong in my build setup ?

Does it come from my profile :

/**
 * This is a new Dojo 1.7 style build profile. Look at util/build/buildControlDefault.js if you want to explore the
 * default Dojo build profile options.
 */

// This function is used to determine whether or not a resource should be tagged as copy-only. See the resourceTags
// property below for more information.
function copyOnly(mid) {
    return mid in {
        // There are no modules right now in dojo boilerplate that are copy-only. If you have some, though, just add
        // them here like this:
        // 'app/module': 1
    };
}

var profile = {
    // basePath is relative to the directory containing this profile file; in this case, it is being set to the
    // src/ directory, which is the same place as the baseUrl directory in the loader configuration. (If you change
    // this, you will also need to update run.js).
    basePath: '..',

    // This is the directory within the release directory where built packages will be placed. The release directory
    // itself is defined by build.sh. You really probably should not use this; it is a legacy option from very old
    // versions of Dojo (like, version 0.1). If you do use it, you will need to update build.sh, too.
    // releaseName: '',

    // Builds a new release.
    action: 'release',

    // Strips all comments from CSS files.
    cssOptimize: 'comments',

    // Excludes tests, demos, and original template files from being included in the built version.
    mini: true,

    // Uses Closure Compiler as the JavaScript minifier. This can also be set to "shrinksafe" to use ShrinkSafe.
    // Note that you will probably get some “errors” with CC; these are generally safe to ignore, and will be
    // fixed in a later version of Dojo. This defaults to "" (no compression) if not provided.
    optimize: 'closure',

    // We’re building layers, so we need to set the minifier to use for those, too. This defaults to "shrinksafe" if
    // it is not provided.
    layerOptimize: 'closure',

    // Strips all calls to console functions within the code. You can also set this to "warn" to strip everything
    // but console.error, and any other truthy value to strip everything but console.warn and console.error.
    stripConsole: 'all',

    // The default selector engine is not included by default in a dojo.js build in order to make mobile builds
    // smaller. We add it back here to avoid that extra HTTP request. There is also a "lite" selector available; if
    // you use that, you’ll need to set selectorEngine in app/run.js too. (The "lite" engine is only suitable if you
    // are not supporting IE7 and earlier.)
    selectorEngine: 'acme',


    localeList: "fr-fr",

    // Builds can be split into multiple different JavaScript files called “layers”. This allows applications to
    // defer loading large sections of code until they are actually required while still allowing multiple modules to
    // be compiled into a single file.
    layers: {
        // This is the main loader module. It is a little special because it is treated like an AMD module even though
        // it is actually just plain JavaScript. There is some extra magic in the build system specifically for this
        // module ID.
        'dojo/dojo': {
            // In addition to the loader (dojo/dojo) and the loader configuration file (app/run), we’re also including
            // the main application (app/main) and the dojo/i18n and dojo/domReady modules because they are one of the
            // conditional dependencies in app/main (the other being app/Dialog) but we don’t want to have to make
            // extra HTTP requests for such tiny files.
            include: [ 'dojo/dojo', 'dojo/i18n', 'dojo/domReady', 'dojo/data/ItemFileReadStore', 'dijit/form/ComboBox'],

            // By default, the build system will try to include dojo/main in the built dojo/dojo layer, which adds a
            // bunch of stuff we don’t want or need. We want the initial script load to be as small and quick as
            // possible, so we configure it as a custom, bootable base.
            boot: true,
            customBase: true
        }
    },

    // Providing hints to the build system allows code to be conditionally removed on a more granular level than
    // simple module dependencies can allow. This is especially useful for creating tiny mobile builds.
    // Keep in mind that dead code removal only happens in minifiers that support it! Currently, ShrinkSafe does not
    // support dead code removal; Closure Compiler and UglifyJS do.
    staticHasFeatures: {
        // The trace & log APIs are used for debugging the loader, so we don’t need them in the build
        'dojo-trace-api':0,
        'dojo-log-api':0,

        // This causes normally private loader data to be exposed for debugging, so we don’t need that either
        'dojo-publish-privates':0,

        // We’re fully async, so get rid of the legacy loader
        'dojo-sync-loader':0,
       
        // dojo-xhr-factory relies on dojo-sync-loader
        'dojo-xhr-factory':0,

        // We aren’t loading tests in production
        'dojo-test-sniff':0
    },

    // Resource tags are functions that provide hints to the compiler about a given file. The first argument is the
    // filename of the file, and the second argument is the module ID for the file.
    resourceTags: {
        // Files that contain test code.
        test: function (filename, mid) {
            return false;
        },

        // Files that should be copied as-is without being modified by the build system.
        copyOnly: function (filename, mid) {
            return copyOnly(mid);
        },

        // Files that are AMD modules.
        amd: function (filename, mid) {
            return !copyOnly(mid) && /\.js$/.test(filename);
        },

        // Files that should not be copied when the “mini” compiler flag is set to true.
        miniExclude: function (filename, mid) {
            return mid in {
                'app/profile': 1
            };
        }
    }
};
Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

PaulChristopher
I would like to know this, too!

At the moment, in my build, all translations are loaded separately.

Is there a way to bake these translations in the layer files (in case you know you support only 2 or 3 languages) using Dojo's 1.7.X build tool?

Or is this not recommanded, since it unnecessarily bloats the layer files? Are these seperate, asynchronous HTTP request (so as to fetch the translations) a performance issue at all? Should I care about them?
Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

PaulChristopher
Or to be more precise: Is it possible to merge e.g. all separate 'en' tanslation files into one single big 'en' translation file so as to get rid off some http request? At the moment, I have 11 http request for language files, 1 request for my main layer "dojo.js".

In the source code (i18nUtil.js), I read something about "flattening of i18n bundles". How can I invoke this functionality form the build profile? Where do I find this newly created "en translation layer"? How do I include it? Using dojo.config's 'deps'-param?

Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

Patrick Ruzand
Hi,

you will have flattened nls bundles for layers that are not a dojo boot layer.
That is, split your dojo layer in two, one for dojo loader itself, and
another one for the rest of the dojo/app modules.

Patrick

n Thu, May 3, 2012 at 10:50 AM, PaulChristopher <[hidden email]> wrote:
> Or to be more precise: Is it possible to merge e.g. all separate 'en'
> tanslation files into one single big 'en' translation file so as to get rid
> off some http request? At the moment, I have 11 http request for language
> files, 1 request for my main layer "dojo.js".
>
> In the source code (i18nUtil.js), I read something about "flattening of i18n
> bundles". How can I invoke this functionality form the build profile? Where
> do I find this newly created "en translation layer"? How do I include it?
> Using dojo.config's 'deps'-param?
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

PaulChristopher
Hi Patrick

thanks for your quick feedback! I have split my app - as suggested - into two layers now: A dojo loader layer and an app layer.

layers: {
        'dojo/dojo': {
            include: ['dojo/dojo'],
            boot: true,
            customBase: true
        },

        'custom/controllers': {
            include: ['custom/controllers/step1', 'dojo/i18n']
        }
}

However all the non english translations are still required in 11 separate calls. If I look at the uncompressed layer file "custom/controllers.js", I can only find the english translations there.

Where can I find the flattend 'fr' or 'de' translation? And how can I tell the loader to use these flattened files?

Or am I doing something wrong when I include my app layer??

I use dojoConfig's deps param for that, and I am not sure if this really works. The main html is basically something like this:

<script> dojoConfig = { deps: ['custom/controllers'] }; </script>
<script src="Scripts/release/dojo/dojo.js" data-dojo-config="async:true, parseOnLoad:true, locale:'de'"></script>
<script> require([ "dojo/ready", "custom/controllers/step1" ], function (ready, controller) { ready(function () { controller.init(); }); }); </script>
The strange thing is: In Firebug's network panel I can see, that the layer gets loaded. But I can also see two extra request for "step1" and "ready" (as given in the code above)! But these two modules should be part of my newly created app layer "custom/controllers"! I do not see these requests if I have just one big dojo/app layer. There I see only 1 request for dojo.js and 11 request for language files...

So something seems to be wrong with my layer??

But what's exactly wrong?

Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

Patrick Ruzand
the nls bundles should be in the custom/nls/ directory.
Also, you have to set the localeList property in your profile; for ex:
localeList: "en,fr,de"

Patrick

On Thu, May 3, 2012 at 3:47 PM, PaulChristopher <[hidden email]> wrote:

> Hi Patrick
>
> thanks for your quick feedback! I have split my app - as suggested - into
> two layers now: A dojo loader layer and an app layer.
>
> layers: {
>        'dojo/dojo': {
>            include: ['dojo/dojo'],
>            boot: true,
>            customBase: true
>        },
>
>        'custom/controllers': {
>            include: ['custom/controllers/step1', 'dojo/i18n']
>        }
> }
>
> However all the non english translations are still required in 11 separate
> calls. If I look at the uncompressed layer file "custom/controllers.js", I
> can only find the english translations there.
>
> Where can I find the flattend 'fr' or 'de' translation? And how can I tell
> the loader to use these flattened files?
>
> Or am I doing something wrong when I include my app layer??
>
> I use dojoConfig's deps param for that, and I am not sure if this really
> works. The main html is basically something like this:
>
>
>
>
>
>
>
> The strange thing is: In Firebug's network panel I can see, that the layer
> gets loaded. But I can also see two extra request for "step1" and "ready"
> (as given in the code above)! But these two modules should be part of my
> newly created app layer "custom/controllers"! I do not see these requests if
> I have just one big dojo/app layer. There I see only 1 request for dojo.js
> and 11 request for language files...
>
> So something seems to be wrong with my layer??
>
> But what's exactly wrong?
>
>
>
> --
> View this message in context: http://dojo-toolkit.33424.n3.nabble.com/Custom-build-dojo-1-7-2-and-nls-files-tp3783493p3959267.html
> Sent from the Dojo Toolkit mailing list archive at Nabble.com.
> ________________________________________________________
> Dojotoolkit: http://dojotoolkit.org
> Reference Guide: http://dojotoolkit.org/reference-guide
> API Documentation: http://dojotoolkit.org/api
> Tutorials: http://dojotoolkit.org/documentation
>
> [hidden email]
> http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest



--
--
Patrick
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

PaulChristopher
Wow, thank you so much, Patrick! It's working now!!!

Is there also a way to make Dojo download the correct language file automatically? At the moment, I still need to manually include the correct flattened language file, e.g. 'custom/nls/controllers_fr.js',  via <script> or a require call in the header of my html file, i.e. the correct flattened language file is not loaded automatically based on the 'dojo.config.locale' setting (as usual).

By the way - refering to http://dojo-toolkit.33424.n3.nabble.com/the-offical-recommended-practice-to-load-a-custom-layer-require-or-lt-script-gt-td3950355.html#a3951043:

Which method do you use now to load a layer: Neither a nested require nor using a simple script tag seem to make a difference: Both trigger the same amount of HTTP request. However there is a difference, when using dojoConfig's deps param (as described above): This gives me some extra two http request (for some unknown reason)....
Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

Patrick Ruzand
On Thu, May 3, 2012 at 4:42 PM, PaulChristopher <[hidden email]> wrote:
> Wow, thank you so much, Patrick! It's working now!!!
>
> Is there also a way to make Dojo download the correct language file
> automatically? At the moment, I still need to manually include the correct
> flattened language file, e.g. 'custom/nls/controllers_fr.js',  via <script>
> or a require call in the header of my html file, i.e. the correct flattened
> language file is not loaded automatically based on the 'dojo.config.locale'
> setting (as usual).

There are several bugs in 1.7.2 fixed in trunk that affect the way the
loader and i18n! handle flattened nls files (aka 1.6 nls layers).
Seems the fixes could be backported in a possible 1.7.3 release (still
to be confirmed).
If you cannot switch to trunk, you can try applying the patch of
http://bugs.dojotoolkit.org/ticket/14989 , and
backport the dojo/i18n.js 28124->28126 revisions. I have done these
steps for my tests and it seems to fix the missing
autoloading/evaluation of the nls bundles.


> By the way - refering to
> http://dojo-toolkit.33424.n3.nabble.com/the-offical-recommended-practice-to-load-a-custom-layer-require-or-lt-script-gt-td3950355.html#a3951043:
>
> Which method do you use now to load a layer: Neither a nested require nor
> using a simple script tag seem to make a difference: Both trigger the same
> amount of HTTP request. However there is a difference, when using
> dojoConfig's deps param (as described above): This gives me some extra two
> http request (for some unknown reason)....

it seems there are no differences. . I *thought* <script> was less
secure, as I noticed some modules  were loaded independently, while
they were included in a layer, and it never happened with the nested
require(). But I don't reproduce now anymore...
________________________________________________________
Dojotoolkit: http://dojotoolkit.org
Reference Guide: http://dojotoolkit.org/reference-guide
API Documentation: http://dojotoolkit.org/api
Tutorials: http://dojotoolkit.org/documentation

[hidden email]
http://mail.dojotoolkit.org/mailman/listinfo/dojo-interest
Reply | Threaded
Open this post in threaded view
|

Re: Custom build (dojo 1.7.2) and nls files.

PaulChristopher
Patrick,

how big is your main dojo "boot layer"? Mine is about 40K (file system size). That's ten times the number given on http://dojotoolkit.org/features/ tab "nano". There, 3.8K is mentioned for the nano loader (gziped I guess)...

Could you make it smaller?

My profile file looks like this:

/**
* This is a new Dojo 1.7 style build profile. Look at util/build/buildControlDefault.js if you want to explore the
* default Dojo build profile options.
*/

// This function is used to determine whether or not a resource should be tagged as copy-only. See the resourceTags
// property below for more information.
function copyOnly(mid) {
    return mid in {
        // There are no modules right now in dojo boilerplate that are copy-only. If you have some, though, just add
        // them here like this:
        // 'app/module': 1
    };
}

var profile = {
    // basePath is relative to the directory containing this profile file.
    basePath: '.',

    // Package information for the builder
    packages: [
        {
            name: "dojo",
            location: "../dojo"
        }, {
            name: "dijit",
            location: "../dijit"
        }, {
            name: "dojox",
            location: "../dojox"
        }, {
            name: "custom",
            location: "."
        }
    ],

    localeList: "en,de,fr",

    // This is the directory within the release directory where built packages will be placed. The release directory
    // itself is defined by build.sh. You really probably should not use this; it is a legacy option from very old
    // versions of Dojo (like, version 0.1). If you do use it, you will need to update build.sh, too.
    // releaseName: '',

    // Builds a new release.
    action: 'release',

    // Strips all comments from CSS files.
    cssOptimize: 'comments',

    // Excludes tests, demos, and original template files from being included in the built version.
    mini: true,

    // Uses Closure Compiler as the JavaScript minifier. This can also be set to "shrinksafe" to use ShrinkSafe.
    // Note that you will probably get some “errors” with CC; these are generally safe to ignore, and will be
    // fixed in a later version of Dojo. This defaults to "" (no compression) if not provided.
    optimize: 'closure',

    // We’re building layers, so we need to set the minifier to use for those, too. This defaults to "shrinksafe" if
    // it is not provided.
    layerOptimize: 'closure',

    // Strips all calls to console functions within the code. You can also set this to "warn" to strip everything
    // but console.error, and any other truthy value to strip everything but console.warn and console.error.
    stripConsole: 'all',

    // The default selector engine is not included by default in a dojo.js build in order to make mobile builds
    // smaller. We add it back here to avoid that extra HTTP request. There is also a "lite" selector available; if
    // you use that, you’ll need to set selectorEngine in app/run.js too. (The "lite" engine is only suitable if you
    // are not supporting IE7 and earlier.)
    selectorEngine: 'acme',

    // Builds can be split into multiple different JavaScript files called “layers”. This allows applications to
    // defer loading large sections of code until they are actually required while still allowing multiple modules to
    // be compiled into a single file.
    layers: {
        // This is the main loader module. It is a little special because it is treated like an AMD module even though
        // it is actually just plain JavaScript. There is some extra magic in the build system specifically for this
        // module ID.
        'dojo/dojo': {

            include: ['dojo/dojo', 'dojo/i18n'],

            // By default, the build system will try to include dojo/main in the built dojo/dojo layer, which adds a
            // bunch of stuff we don’t want or need. We want the initial script load to be as small and quick as
            // possible, so we configure it as a custom, bootable base.
            boot: true,
            customBase: true
        },

        'custom/layer': {

            include: ['custom/controllers/step1']

        }
    },

    // Providing hints to the build system allows code to be conditionally removed on a more granular level than
    // simple module dependencies can allow. This is especially useful for creating tiny mobile builds.
    // Keep in mind that dead code removal only happens in minifiers that support it! Currently, ShrinkSafe does not
    // support dead code removal; Closure Compiler and UglifyJS do.
    staticHasFeatures: {
        // The trace & log APIs are used for debugging the loader, so we don’t need them in the build
        'dojo-trace-api': 0,
        'dojo-log-api': 0,

        // This causes normally private loader data to be exposed for debugging, so we don’t need that either
        'dojo-publish-privates': 0,

        // We’re fully async, so get rid of the legacy loader
        'dojo-sync-loader': 0,

        // dojo-xhr-factory relies on dojo-sync-loader
        'dojo-xhr-factory': 0,

        // We aren’t loading tests in production
        'dojo-test-sniff': 0,

        // Neonstalwart's tweaks, see http://comments.gmane.org/gmane.comp.web.dojo.devel/15941
        'config-dojo-loader-catches': 0
        /*
        'dom': 1,
        "host-browser": 1,
        "dojo-inject-api": 1,
        'dojo-combo-api': 0,
        'host-node': 0,
        'host-rhino': 0,
        "dojo-sniff": 0,
        "dojo-undef-api": 0,
        "config-tlmSiblingOfDojo": 0,
        "dojo-timeout-api": 0,
        "dojo-amd-factory-scan": 0,
        "dojo-requirejs-api": 0,
        "dojo-dom-ready-api": 1,
        "ie-event-behavior": 1,
        "dojo-config-api": 1*/
    },

    // Resource tags are functions that provide hints to the compiler about a given file. The first argument is the
    // filename of the file, and the second argument is the module ID for the file.
    resourceTags: {
        // Files that contain test code.
        test: function (filename, mid) {
            return false;
        },

        // Files that should be copied as-is without being modified by the build system.
        copyOnly: function (filename, mid) {
            return copyOnly(mid);
        },

        // Files that are AMD modules.
        amd: function (filename, mid) {
            return !copyOnly(mid) && /\.js$/.test(filename);
        },

        // Files that should not be copied when the “mini” compiler flag is set to true.
        miniExclude: function (filename, mid) {
            return mid in {
                'custom/app.profile': 1
            };
        }
    }
};