define('backbone/backbone', ['require', 'exports', 'module'], function (require, exports, module) {(function(){var root = this;var previousBackbone = root.Backbone;
define('backbone/backbone', ['require', 'exports', 'module'], function (require, exports, module) {(function(){\n\n var root = this;\nvar previousBackbone = root.Backbone;
moduleText = jsEncode(text) + ';\n'+ 'define("' + absId + '", function () {\n';moduleText += exports? '\treturn ' + exports: '\treturn void 0';moduleText += ';\n});\n';
io.read(resId, function (text) {io.write(jsEncode(wrapCjsm11(text, moduleId)));}, io.error);
fyi with commonjs loader the file that it is having a problem opening does exist/home/vagrant/conversocial/static/lib/backbone/backbone.jsPerhaps it's looking for the file but missing the .js extension?** EDIT **I'm not sure if it's cram or curl at fault but the above appears to be the problem. Here's a patch that makes it work to illustrate:https://github.com/cujojs/curl/pull/205
On Saturday, 10 August 2013 22:37:09 UTC+1, Gehan Gonsalkorale wrote:
I assume I can just exclude lodash for now and it'll still build?
6 - run.jsYes it works fine for me, not sure why I thought otherwise. Since the module defs were below I thought it was going to do something else. I suppose since javascript is single-threaded and the curl call is asynchronous, it actually runs all the defines at the bottom before actually executing the curl('wire!) bit?
<span data-bind="text: replyTypeText"></span>
<span data-bind="text: replyTypeText">@Reply</span>
<span data-bind="text: replyTypeText">function m(){if(0<arguments.length){if("function"===typeof r)r.apply(c,arguments);else throw Error("Cannot write a value to a ko.computed unless you specify a 'write' option. If you wish to read the current value, don't pass any parameters.");return this}l||e();a.q.bb(m);return k}</span>
layoutView:render:template:module: 'text!app/conversations/views/layout.html'replace:module: 'i18n!app/conversations/strings'
app/conversations/strings.jsapp/conversations/strings/en.jsapp/conversations/strings/en-us.js
define('curl/plugin/i18n!app/main/strings', function () {return {};});
;define('curl/plugin/i18n!app/conversations/strings/en-us', function () {return {'menuInbox': 'Inbox'};});;define('curl/plugin/i18n!app/conversations/strings/en', function () {return {'menuInbox': 'Inbox'};});;define('curl/plugin/i18n!app/conversations/strings', function () {return {};});
// Define all the locale modules as maps
define('curl/plugin/i18n!app/strings/de', {
'someString': 'someGermanString'});define('curl/plugin/i18n!app/strings/en-us', {'someString': 'someEnUSString'});define('curl/plugin/i18n!app/strings/en', {someString': 'someEnString'});
// For the actual strings module, define the defaults and then call some other
// module to determine the locale and try to load the appropriate language file.
define('curl/plugin/i18n!app/strings', ['curl/plugin/i18nRunner'], function(i18n) {var defaults = {'someString': 'someDefaultString'};i18n(defaults);});
1. Extract the getLocale() function into a separate module, and move the config-related logic into it so it can also check for run-time overrides of the locale. So now we have a module that returns getLocale(config) --> string|boolean. This can be used by the curl i18n plugin (run-time plugin) and injected into the build by the cram i18n plugin (build plugin).
2. Make a new build plugin config option, `availableLocales` -- or just `locales`, perhaps? The build plugin should attempt to load the modules for each locale using the run-time plugin, keeping a hashmap of all of the modules that are successfully loaded. All of these modules will be output to the bundle. At run-time, the list of locales included in the build must be available so we know if getLocale() returns something we have or not. I am thinking that we should not force the dev to specify this list again at run-time: we have to "bake" it into the bundle.
3. Make a new curl / run-time option to help decide whether to attempt to fetch locales that aren't in the bundle. Actually, I think we already have this option: `locale: false`. If the locale bundle is missing and `locale == false`, the default bundle is used. Otherwise, it is fetched. (Side note: the i18n plugin will have to be fetched, too, if it is not already loaded.)
4. (Optional) Make a new build plugin option, `merge`. If `merge` is false (default), the behavior in (2) will be used. If it is true, a procedure much like the existing code will be used. The existing code merges all specificities of the i18n bundles into one bundle (default, en, en-gb, for instance). I'm not sure how useful this would be in the real world, but the code i already there, so I just wonder if some people might prefer to pre-merge the bundles.5. Change the build plugin so it outputs something that encompasses all of the above. I'll have to put some more thought into exactly what this means, but it seems like it would follow from implementing the previous parts of the plan. At a minimum, we'll need to output the locale bundles, the list of locale bundles included in the build, some code to determine whether to fetch a locale bundle that is not already loaded, and some code to merge bundles at run-time (`merge: false`).
Problems:1. In order to avoid configuration scope issues, users will have to specify the `locale` run-time config option at the top-level. Using `{ plugins: { i18n: { locale: 'fr' } } }` will limit the scope of `locale` to just the i18n plugin which may have been eliminated at build time. I just wrote some code docs about this.
What do you think?
To view this discussion on the web visit https://groups.google.com/d/msgid/cujojs/36bbb735-b1ef-4401-be65-f13504c9d48e%40googlegroups.com.--
You received this message because you are subscribed to a topic in the Google Groups "cujojs" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cujojs/Gt1Fof6tjOk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cujojs+un...@googlegroups.com.
To post to this group, send email to cuj...@googlegroups.com.
Visit this group at http://groups.google.com/group/cujojs.
--
You received this message because you are subscribed to the Google Groups "cujojs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cujojs+un...@googlegroups.com.
To post to this group, send email to cuj...@googlegroups.com.
Visit this group at http://groups.google.com/group/cujojs.
To view this discussion on the web visit https://groups.google.com/d/msgid/cujojs/936ed7f6-26eb-49cd-b6e3-2e9af71823f1%40googlegroups.com.