First pass at default order convention

[Cheetham, Anastasia]

On 2013-01-31, at 9:40 AM, Justin Obara wrote:

> As part of the community meeting yesterday we talked about developing a convention for how we order our options in a components defaults. Below is the first pass at developing that convention. Please provide feedback and alternatives as necessary. Also, feel free to add in any missing options.

This looks pretty good, Justin. The comments on the groups really help to make it clear what's what.

One thing I notice (and like) is the grouping of options related to specific grades (renderer, view, etc). I think that makes a lot of sense. With that conceptual grouping going on, would it make sense to keep all of the grade-based groupings together? That would mean moving the event-related options up before the component-specific options. It's only a small change, but since we're thinking this through…

I've also added a couple of renderer-specific options.

So it might look like this:

fluid.defaults("fluid.component", {

   // gradeNames should always go first, so we know what "type" of component is being defined.
   gradeNames: ["fluid.rendererComponent", "autoInit"],

   // init functions should go next
   // note these can be inferred by the framework now, and soon will be obsolete
   preInitFunction: "fluid.component.preInit",
   postInitFunction: "fluid.component.postInit",
   finalInitFunction: "fluid.component.finalInit",

   // standard option for model defaults
   model: {},
   applier: ""

   // standard options for defining view related options
   selectors: {},
   strings: {},
   styles: {},

   // event related options
   events: {},
   listeners: {},

   // standard options for renderer components 
   renderOnInit: true,
   selectorsToIgnore: [],
   repeatingSelectors: [],
   protoTree: {},  // mutually exclusive with produceTree
   produceTree: "",
   rendererFnOptions: {},
   rendererOptions: {},

   // templates, usually used with renderer components
   resources: {} // template

   // component specific options
   compOpt1: "",
   compOpt2: {},
   compOptETC: [],

   // component methods
   invokers: {},

   // child components
   components: {}
});

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