When is a subcomponent not a subcomponent?

[Antranig Basman]

On 29/06/2011 17:17, Cheetham, Anastasia wrote:
>
> I'm working out how to document an IoC-ified component – in particular, how to communicate the various "things" that need to be or can be configured. I'm looking for input on what terminology to use to refer to these "things" in the user-facing API documentation.
>
> For example, in UI Options:
>
> 1) "fluid.uiOptionsTemplateLoader" is something that integrators will most likely need to configure: It identifies the path(s) to the various templates.
> 2) The "fluid.textfieldSlider"s have selectors that integrators need to know about, so that they can either use the defaults or override them.
>
> The issue is this: These two things are NOT technically subcomponents of anything:
> - #1 is an expander of an expander of a resource of a subcomponent.
> - #2 is a decorator on the renderer component tree of a subcomponent.
>
> I'm sure this issue will come up to some degree in most of the components we IoC-ify.
>
> Would it be unacceptably dishonest to simply refer to these (and similar things that integrators need configure) as "Configurable Subcomponents" in the user-facing API documentation? What do people think? Pros? Cons? Other suggestions?
>

Hi Anastasia - yes, this discussion is always interesting. Our previous 
position (before IoC) established that whether "something is a 
subcomponent" is purely a function of its relation to some other thing 
(that is, "configured as a subcomponent of the thing") rather than an 
inherent property of the thing itself. This is only more true in the IoC 
era than it was before.

In terms of your two cases - in #2, since a few months ago, decorators 
of this kind that create a "fluid decorator" creating a component as 
part of a renderer tree, actually *do* create a subcomponent, configured 
via IoC, attached to the parent. These are the subcomponents which are 
accessible via the new API
fluid.renderer.getDecoratorComponents as part of RendererUtilities.js
  - so, no dishonesty required, these are genuine subcomponents in every 
sense.

The situation with #1 is more unclear - the expander may end up creating 
a subcomponent, or it may not. So I think in that case it would be 
unacceptably dishonest to always describe the material as a 
"configurable subcomponent". But going further, it will be unlikely, 
bordering on impossible, for an integrator to expect to interact with 
material held in expanders - they are a kind of "one-shot deal". The 
integrator could write NEW expanders which replace some of the old ones, 
but probably not happily interact with existing ones. In general 
expanders themselves are solutions which we are not particularly happy 
with and will be replaced by new primitives as part of the "Model 
Transformation" work in Infusion 1.5.

Cheers,
Antranig