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? -- Anastasia Cheetham Inclusive Design Research Centre [email protected] Inclusive Design Institute OCAD University _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
