When is a subcomponent not a subcomponent?

[Cheetham, Anastasia]

Antranig, thanks for your thoughts. The reason I'm asking about what to call these things is for the integrator-facing documentation, which essentially wants to say "Here are some 'things' that you'll need to configure to use this component," and the question is: Could I use, as a generic phrase, 'configurable subcomponents' for 'things.'

You can see a typical context here:
    http://wiki.fluidproject.org/display/fluid/UI+Options+API+%28in+development%29
at the bottom of the first "summary" table.

One comment on your comments:

On 2011-07-07, at 3:30 PM, Antranig Basman wrote:

> The situation with #1 is more unclear - the expander may end up creating a subcomponent, or it may not. ... 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...

This is an interesting comment. The particular example I gave, "fluid.uiOptionsTemplateLoader" is an expander that the vast majority of UIOptions integrators *will* be required to interact with: They must create a demands block to specify the location of the templates.

Maybe that's not what you were thinking of when you use the phrase "interact with?"

-- 
Anastasia Cheetham     Inclusive Design Research Centre
acheetham at ocad.ca            Inclusive Design Institute
                                        OCAD University