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