another neat IoC framework

[Antranig Basman]

Yes, it is interesting - it solves a different, somewhat more coarsely-grained problem than our IoC 
framework. require.js is only is prepared to deal with dependency statically, that is at the unit of blocks 
of code forming implementation modules, rather than that which arises in amongst the implementation 
structure of a particular application - and also it makes no attempt to deal with the "context" problem, 
that is, those contextual features of the user's needs which may require a different implementation for the 
same function in different contexts. Cast in OO terms, there is no potential for "polymorphism" in a 
standard require.js module structure.

Actually the problem it solves is somewhat complementary to ours, and is not one that we have made any 
attempt to address so far, which is the issue of how application code and other needed resources are located 
and loaded. So it is not impossible that at some point we might move over to require.js or something like it 
in order as a base framework to manage our implementation modules and resources, especially since we now 
seem to have pretty much figured out how the node/commons module loading system is meant to interact with 
the code loading requirements of code operating Fluid IoC (see our GPII work for the use of what is being 
called the "Fluid module convention").

In this model, you would imagine that the Fluid IoC system, from an inspection of the dependency structure 
between the JSON configuration blocks held in some defaults/demands, would issue a set of directives to 
require.js of the form in section 1.2.3 of its docs http://requirejs.org/docs/api.html#defdep - which would 
then operate the actual code load required.

Right now the only loss we face is the loading of potentially unnecessary modules which might end up not 
used in a particular context - this cost is small right now but as our architecture scales and faces 
stronger performance demands will become more significant. So we'll need to address this issue in due time - 
direct use of require.js might in theory be attractive, so long as we could persuade it to defer to the use 
of fluid.require rather than the platform's vanilla "require" when it did any loading - this is necessary 
since Fluid IoC-aware code all needs to be loaded into the same global namespace held in a distinguished 
module, rather than all ending up in separate, unnamed namespaces as happens by default in the standard 
node/commons module loading idiom.



On 21/06/2012 18:43, Novak, Alexey wrote:
> Did you guys see this one before?
> http://requirejs.org/
>
> Pretty interesting with lots of documentation about it.
>
>