Thanks, Alexey, this is indeed a helpful explanation motivating IoC. Actually I met Brian at the jsconf
presentation where he delivered these slides and found him a very pleasant and highly switched-on chap :)
Unlike require.js, wire.js is indeed a "true IoC framework" in the sense I described in my earlier message
on this thread - it is capable of recursive dependency resolution, and the bindings of names onto
implementations are encoded in declarative structures rather than in code. It is aimed at many of the same
goals as our framework - a "wiring specification" meets many of the goals of the declarative specification
which we provide in our "defaults blocks".
wire.js is ahead of our framework in providing facilities in some areas, and behind in some other areas. A
lot of its idiom is determined by aiming for the maximum possible naturalness and idiom in interacting with
the node.js/Commons module loading specification, which we've decided for some time (and especially more
recently with our GPII work) isn't a broad enough base for us to build on for Fluid's aims.
In particular, wire.js has these advantages:
i) An official and regular set of lifecycle points for components (5-stage model described at
https://github.com/cujojs/wire/wiki/Component-lifecycles ) - this is something we have had on the cards for
a while but so far only have "events" covering phases of early initialisation (preInit, postInit, etc.). The
required extension for us is JIRAed at http://issues.fluidproject.org/browse/FLUID-4257
ii) A natural ability to name and load an implementation from a (node) module
using syntax like create: {
module: 'hello-wired',
since our scheme for code loading in Fluid only has a sketch implementation (the "fluid.require" system
which directly invokes platform require) we currently operate a simple scheme which assumes that all
necessary code has already been loaded.
iii) Good support for asychronously completing activities through the use of "promises" described on
https://github.com/cujojs/wire/wiki/Factories - this allows CommonsJS compliant "promises" to be used to
govern a wiring sequence. We plan to support such facilities in the future through an extension of our
"event boiling syntax", our existing implementation described here:
http://wiki.fluidproject.org/display/docs/Event+injection+and+boiling
iv) Good support for orchestrating DOM insertion (including templating) and querying activities in amongst
component initialisation. Currently our renderer in Fluid, although offering very good decoupling between
markup and components, is very inflexible in its timing and behaves badly in scenarios where rendering
components are nested. It is also tightly integrated into our component grade structure via
"rendererComponent" and so hard to replace.
Fluid supplies a mature "events" system to deal with points i) and iii) but currently offers no framework
support to guide the operation of component lifecycle points and incorporating asynchronous activities into
the wiring (configuration) sequence - the user at the moment is on their own.
There are the following areas where the dynamism provided by wire.js isn't
enough for our needs:
a) Whilst module dependency specification has been shifted out into configuration material, it is not easy
to allow for "polymorphism" in implementation. wire.js has no equivalent to our demands blocks system, which
allow an integrator or other developer to selectively override parts of a configuration used by a 3rd party,
whilst retaining others. wire.js provides for this use case via its "aop" and "facets" system which are
based on function handles containing code, rather than operating on configuration directly. wire.js does
provide the "prototype" system ( https://github.com/cujojs/wire/wiki/Factories ) which can be seen as
similar to our "grades" system, allowing new names to be created for new implementations - however, there is
no facility for existing implementations to be modified based on context of use.
b) The absence of stable global names in wire.js (inherited from the modules system) makes it even harder to
deal with point a) - an implementation may be imported from a module, but cannot be reliably identified or
contrasted with or combined with other implementations in other modules.
c) The particular models for asynchrony (promises) and DOM binding (special syntax for referring to
elements) are not sufficiently "open". In practice there are multiple models for asynchronous processes
(indeed, there are multiple Promises libraries even within JS, ignoring other models such as Actors/Monads
etc. ) and it is impractical to expect all users to commit to exactly one model as "primary" and use
adaptors to express every other model in these terms (even if this is possible, in practice it often isn't).
Similarly, DOM binding lacks our model for indirection using the "DOM binder" which allows integrators or
other developers to find a well-defined place for all DOM binding information where it may be overridden or
reconfigured.
A big foundational difference can be seen on the wire.js page on contexts -
https://github.com/cujojs/wire/wiki/Contexts - In Fluid IoC, *every* component automatically becomes usable
as a context, rather than there being a separate concept of "context objects". Whilst wire.js contexts do
form a hierarchy, each individual context is "flat". In this example -
https://github.com/cujojs/wire/wiki/connect-things - the references "component1.doSomethingBefore" etc. can
be seen as somewhat analogous to a Fluid IoC value reference "{component1}.doSomethingBefore" - but the
referential power of the 1st path component in wire.js is weaker - it must refer to a component explicitly
configured with that name in this or a parent context.
There are various other points of difference that could be viewed at length, but hopefully this is enough to
give a reasonable idea of the major points of similarity and difference in implementation and philosophy.
Certainly it is comforting to know that there is at least some other work on "strong IoC" in the JavaScript
community, which should help familiarise the community with these concepts.
Cheers,
Antranig
On 29/06/2012 10:04, Novak, Alexey wrote:
It has a very well explained concept and why would you consider IoC (I find it
by far one of the best
explanations)
If you step through all slides there will be a link to github.
http://briancavalier.com/presentations/wirejs-2011-jsconf/#0
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
