Hey,
On 1-Jun-09, at 9:30 AM, antranig at caret.cam.ac.uk wrote:
> I have created a small page where I have written up some of our recent
> discussions on the need/mechanism for IoC within our framework -
>
> http://wiki.fluidproject.org/display/fluid/IoC+Speculations
This looks really good. A slightly goofy but highly informative
document. ;)
Here's my attempt to summarize it for those who haven't had a chance
to take an in-depth look:
Inversion of control is a key technique for ensuring that Infusion
components can be wired up in a very loosely-coupled way, allowing
them to be adapted and configured easily. We've had a simple form of
IoC in Infusion since 0.5, but have found that it's not sufficient for
managing more complex interactions between components. In particular,
declaring a dependency is essentially unidirectional--parent to
child-- so code needs to be changed every time a child requires a new
dependency from its parent.
We're proposing adding a more sophisticated IoC container to the
Infusion framework, but one that uniquely doesn't take away our users'
ability simply instantiate components in the familiar way. They can
still just invoke a component's creator function, and don't need to be
aware of the container's existence unless they want to be.
Dependencies will be declared on a per-context basis, using
"constructor-style" injection. Each component simply declares the
things it needs in given context, and components can be configured
differently depending on the type of their parent.
All considered, this approach should simplify our code and improve our
ability to offer super-flexible components. This new IoC container
will also serve as the basis for a much more sophisticated approach to
progressive enhancement and customization with UI Options. We can add
it in while still preserving backwards compatibility, too.
A couple of questions/comments for you, Antranig:
* Do we need to qualify properties with "that," or can it simply be
assumed? Where else could a subcomponent pull dependencies from,
except from its parent? So for example, your code here:
fluid.demands("fluid.pager", "fluid.pager.renderedPageList",
["that.container", "that.events", "that.pagerBar.options",
fluid.COMPONENT_OPTIONS, "that.options.strings");
* As far as naming goes, my vote is to call the dependency registrar
fluid.dependencies() or fluid.wiring()
* As it stands now, components need to specifically support
decorators, and the signature for all decorators is fixed. This
approach seems to provide us with a totally general system for
component decorators. Is that right?
Colin
---
Colin Clark
Technical Lead, Fluid Project
Adaptive Technology Resource Centre, University of Toronto
http://fluidproject.org