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