flesh out to give more explanation
update code samples to latest form
remove anything without 'autoInit'
- remove mention of lifecycle functions
- remove mention of initDependents
Remove mention of demands
We've decided that demands blocks will no longer be used or recommended, so we will remove references to them altogether. They should be replaced with either the use of distributeOptions, or with a grade that overrides things.
The two pages have been removed. The rest of the docs still need to be reviewed.
Invokers
fast invokers, dynamic invokers, compact syntax
Justin,
Antranig to review
Component Grade page Component Grades
combining grades
creating your own grades
- and then cover dynamic grades, both supplied via direct options as well as those resolved
via an IoC reference in the "gradeNames" list - explain the limitations on this latter process
and how it must be used carefully.
dynamic grades and grade merging
ability to write an ioc expression where a grade name is expected
See for notes that might be helpful.
Model Transformation
update to reflect latest code
transforms now in "fluid.transforms" namespace
many new transforms available (see ModelTransformationTransforms.js)
transforms now specified with "transform:" instead of "expander:"
Some docs exist in the GPII wiki:
http://wiki.gpii.net/index.php/Architecture_-_Available_transformation_functions
rename it! explain it somewhere where appropriate
ensure any code samples reflect current APIs, practices, features, etc
ensure text reflects current framework
add new features where appropriate
- How to Use Infusion IoC Needs to be reviewed and brought up-to-date to reflect current best practices (e.g. no demands, IoCSS, etc)
- Subcomponent Declaration and dynamic components
- Contexts
diagram from demand resolution page, plus some explanation
- Pseudoarguments
- "a demands block which uses named arguments such as "options", "container", etc. rather than an argument list"
Message loading: We need an overview page describing how to work with message files/string bundles, for localization, including
- in renderer components
- using the message resolver (fluid.messageResolver) in non-renderer-component scenarios
- Update the scenarios, use to identify "paths through the docs"
configuration only
declarative listeners
declarative prototrees
declarative invokers and events
convey the fact that you're developing something that might be used by future authors
What are the mechanisms by which an author would make an application reconfigurable?