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" <[email protected]> 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 > [email protected] Inclusive Design Institute > OCAD University > > <winmail.dat> _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
