First pass at default order convention

Cheetham, Anastasia acheetham at ocadu.ca
Thu Jan 31 16:01:00 UTC 2013


On 2013-01-31, at 10:53 AM, Justin Obara wrote:

> In terms of where the events are. I kind of like having the renderer options close to the view ones, as they are more semantically related to one another. However, it's not a deal breaker for me either way. If we did move events, I think it might make sense to place them closer to the model options or below the renderer ones. 

Well, keeping renderer options close to view ones makes a lot of sense. Moving the events up closer to the model options also makes sense.

Let's try 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: ""

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

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

 // 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




More information about the fluid-work mailing list