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
_______________________________________________________
fluid-work mailing list - [email protected]
To unsubscribe, change settings or access archives,
see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
