IoC Speculations

[antranig at caret.cam.ac.uk]

Quoting Colin Clark <colin.clark at utoronto.ca>:
> Hey,
>
> Sorry for the delay in responding to this thread, but one further
> question...
>
> On 8-Jun-09, at 2:26 PM, Antranig Basman wrote:
> >> 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");
> >
> > Yes, my idea for qualification was to be able to refer not only
> > specifically to the "immediate that", that is, the "that" of the
> > component which is most immediately executing initSubcomponents,
> > but also any "outer nested thats" - that is, any others in whose
> > initSubcomponents this instantiation may be nested. This is what
> > is proposed about 3/4 of the way down with syntax perhaps like
> > "that{fluid.pagerBar}.options".
> > I also imagined that any string not beginning with "that" would
> > simply be resolved as a global EL path, for example to some
> > constants that were sitting in the fluid.* space or some others.
>
> I'm still not entirely clear on this. What exactly are we referring to
> with the {fluid.pagerBar} qualification? Perhaps a concrete example
> might clarify?

Hi Colin - thanks for the question.
Yes, actually we have a ready-made example in the form of our current
setup for the pager - not in fact that we want to keep it, but at least
it exemplifies the use case:P

So, the top-level pager has its options, it then issues
initSubcomponents in order to create a "pagerBar" element:

that.pagerBar = fluid.initSubcomponent(that, "pagerBar",
      [that.events, pagerBarElement, fluid.COMPONENT_OPTIONS,
that.options.strings]);

Now, of itself, pagerBar during its own initialisation through this
call makes a further call to initSubcomponents on its own behalf,
to initialise even smaller things, like the "pageList", etc.

that.pageList = fluid.initSubcomponent(that, "pageList",
           [container, events, that.options, fluid.COMPONENT_OPTIONS, strings]);

So - these are all currently "old-style" calls which manually name both
the particular subcomponent to be created as well as all its direct
arguments.

Now "it is clear" that during the 2nd call to initSub, the first call
is still on the stack, still in the middle of the constructor for the
top-level pager. It would seem to be useful, when we move all of this
over to the "new style", to be able to issue "qualified references to
'that'". When the pageList, for example, makes reference to "strings" -
the "ultimate home" of this option is actually as a member of the
top-level "that", two components up - so we would like to be able to
refer to this somehow, without necessarily bothering the middle
component. So, a syntax like, "that{fluid.pager}.options.strings" would
explicitly qualify the fact that we are talking about a "that" at
a particular other level of construction, rather than the
"immediate that" - strings starting simply with "that" would always
implicitly refer to the particular that which "most recently"
invoked initSubcomponents.

Hope this makes the motivation for the notation clearer - in general,
I guess, we should avoid deeply nested component instantations
in general.

Antranig.


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.