Hi Alexey - thanks for the question.
The first and most basic answer, about what you have to do to implement
IoC (I guess, starting from a standard app without it) is to give up the
ability to directly refer to function names when trying to invoke some
other piece of code to do work for you. In a Java/C# app, these names
which you can give up using are generally only constructor names. These
names end up moved out into a some other form of configuration, a
declaratively written data structure rather than directly forming part
of the source code.
A simplest example of a "complete" IoC system is described in this part
of the Spring documentation, a system where code is written in Java and
and configuration in XML:
http://static.springsource.org/spring/docs/3.0.x/spring-framework-reference/html/beans.html#beans-factory-collaborators
In these terms, require.js is not actually an IoC framework at all. It
doesn't actually do anything to decouple names from implementations - if
you want an application that does something different when a module,
say, demands "./cart" as a dependency, you actually need to move
implementation files around in the filesystem or swap them out. Spring
is a true IoC framework, since changing binding of a name onto an impl
can be done just by editing/swapping a configuration file.
Spring doesn't go far enough, since you still need to change a file! A
truly flexible application can alter its binding from moment to moment,
in response to a change in context, without involving fresh development
effort (swapping out one file in the app for another) or restarting the app.
There are a number of other ways in which Infusion IoC goes further -
given JS is based on JSON, it is possible to deliver dependencies,
whether they consist of data or functions, at arbitrary points within a
complexly structured argument or component, rather than being limited to
"getter/setter" injection points as you are in Java/C#.
As you mention in your question, the parent/child issue is also an
important extension in Infusion - the resolution process in the
framework moves up a tree of instances, rather than looking things up in
a static container. However, this isn't important to the basic
distinction of being an IoC system or not. The basic skeleton of this
lookup process is present in Spring, which rather than dealing with a
runtime hierarchical object, looks up "beans" in a flat,
application-scoped container.
Sorry for this long answer, which probably isn't even complete or very
helpful - do ask again about some issue, and I'll try to reply more briefly.
Cheers,
Antranig
On 22/06/2012 15:06, Novak, Alexey wrote:
> Hi Antranig,
>
> I have a question for you. I know that in IoC the children ask for
the resources of the parent which eliminates the standard approach when
parent passes a piece of its information to its children. Basically IoC
eliminates the case when a variable is falling through from the parent
to its children to its children' children and so forth….
> How does children have an access to the parent's resources in
inFusion? I'm curious what is the concept you used which allowed to make
it happen?
>
> Also maybe if it clarifies my question - If I'm writing the standard
JS or C# app and I do not use the frameworks how would I implement IoC
there; in particular how would I make this link between children and its
parent so that a child can ask resources of the parent?
>
> Hopefully my question is clear enough.
> Thanks,
>
> Alex
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
