requirejs, loader, .deploy.js

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

requirejs, loader, .deploy.js

Herby Vojčík
Hello!


A.

AFAICT, the requirejs branch is ready to use and contains all features
with one exception I will cover later.


B.

No globals are defined at all: amber.js is defined in such a way that it
just configures require.js (or any conforming loader) and you should
load amber as well as your packages by using AMD loader directly. Like
in this example:

     require.config({
         config: {
             'amber_vm/smalltalk': {
                 defaultNamespace: 'amber'
             }
         }
     });
     require(
         ["amber_vm/smalltalk", "amber_set/full-devel"],
         function (smalltalk) {
             smalltalk.initialize();

             smalltalk.Browser._open()
         }
     );

First, you should tell amber which namespace it should add to newly
created packages. If you are sure no new packages are going to be
created (besides ones loaded), you could eschew the first call (well,
not really, see two paragraphs below).

The second call simply loads amber and well-known set of packages, you
can add your own packages to the array. In a function, you must call
initialize by hand, then any start code you want to happen. This is the
price of not having the globals, so no "smart" wrapper that would know
when to call initialize.

If you load your own packages (that are in your own namespaces), you
should put path mappings in the require.config call. Thus, it is almost
inevitable that there will be one require.config call and then one
require call with list of packages to load and code to run afterwards.

This is more complicated then simple loadAmber(), but in practice, it
was longer, you had to list packages at least anyway; and nothing more
than these two calls is really needed. Also, keeping it on amd level is
friendlier to different kind of embedding and mixing scenarios.


C.

There is still no general way (it wasn't there before, as well, just to
mention, only the core was loaded from .deploy.js, the rest was always
full .js) to use .deploy.js instead of .js. The partial solution (only
remap core to .deploy.js) is possible by specific configuration of
require.js. But because of no-globals (B. above) the remapping is not
present as a function (it is in fact not present at all, because I don't
know where to put it or whether to put it there at all now), it may be
put in different file that can be loaded after amber.js (but it sort-of
defeats the purpose of .deploy.js to be loaded asap). For me, the best
solution would be not to care of .deploy.js at all, changing the way it
is compiled so that it is put in different directory, and just mapping
the right path at deploy time.


Herby

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.
Reply | Threaded
Open this post in threaded view
|

Re: requirejs, loader, .deploy.js

Nicolas Petton
thanks Herby for the detailed email :)

I agree about .deploy.js, I would remove them completely and provide an app based deployment solution. I'll see if I can read everything in your branch before merging :)

Nico

On Aug 26, 2013, at 2:16 PM, Herby Vojčík <[hidden email]> wrote:

> Hello!
>
>
> A.
>
> AFAICT, the requirejs branch is ready to use and contains all features with one exception I will cover later.
>
>
> B.
>
> No globals are defined at all: amber.js is defined in such a way that it just configures require.js (or any conforming loader) and you should load amber as well as your packages by using AMD loader directly. Like in this example:
>
>    require.config({
>        config: {
>            'amber_vm/smalltalk': {
>                defaultNamespace: 'amber'
>            }
>        }
>    });
>    require(
>        ["amber_vm/smalltalk", "amber_set/full-devel"],
>        function (smalltalk) {
>            smalltalk.initialize();
>
>            smalltalk.Browser._open()
>        }
>    );
>
> First, you should tell amber which namespace it should add to newly created packages. If you are sure no new packages are going to be created (besides ones loaded), you could eschew the first call (well, not really, see two paragraphs below).
>
> The second call simply loads amber and well-known set of packages, you can add your own packages to the array. In a function, you must call initialize by hand, then any start code you want to happen. This is the price of not having the globals, so no "smart" wrapper that would know when to call initialize.
>
> If you load your own packages (that are in your own namespaces), you should put path mappings in the require.config call. Thus, it is almost inevitable that there will be one require.config call and then one require call with list of packages to load and code to run afterwards.
>
> This is more complicated then simple loadAmber(), but in practice, it was longer, you had to list packages at least anyway; and nothing more than these two calls is really needed. Also, keeping it on amd level is friendlier to different kind of embedding and mixing scenarios.
>
>
> C.
>
> There is still no general way (it wasn't there before, as well, just to mention, only the core was loaded from .deploy.js, the rest was always full .js) to use .deploy.js instead of .js. The partial solution (only remap core to .deploy.js) is possible by specific configuration of require.js. But because of no-globals (B. above) the remapping is not present as a function (it is in fact not present at all, because I don't know where to put it or whether to put it there at all now), it may be put in different file that can be loaded after amber.js (but it sort-of defeats the purpose of .deploy.js to be loaded asap). For me, the best solution would be not to care of .deploy.js at all, changing the way it is compiled so that it is put in different directory, and just mapping the right path at deploy time.
>
>
> Herby
>
> --
> You received this message because you are subscribed to the Google Groups "amber-lang" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
> For more options, visit https://groups.google.com/groups/opt_out.

--
Nicolas Petton
http://www.nicolas-petton.fr

--
You received this message because you are subscribed to the Google Groups "amber-lang" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/groups/opt_out.