When is a subcomponent not a subcomponent?
antranig.basman at colorado.edu
Thu Jul 7 19:30:21 UTC 2011
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
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.
More information about the fluid-work