First pass at default order convention

[Justin Obara]

Thanks for catching those missed renderer options. 

I'm happy with the changes you've made too. In particular the grouping of the component specific options adjacent to the invokers. I figure many of these will fit into the new section we talked about at the meeting yesterday for adding properties onto a component, and having them close to the components methods would make sense. 

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. 

Thanks
Justin

On 2013-01-31, at 10:43 AM, "Cheetham, Anastasia" <acheetham at ocadu.ca> wrote:

> 
> 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
> 
> <winmail.dat>