Hi everyone, So based on the today's conversation we ended up narrowing down the possible names for options in the "out of the box" category to: |starter| and |basic|.
I will update my pull request asap. Please, if you have any preferences or concerns regarding the chosen names, reply to this thread. Regards, Yura On 2013-06-04, at 10:36 AM, Justin Obara <[email protected]> wrote: > I've given this some more thought today, and have the following suggestions. > > fluid.uiOptions.defaultSettingsPanels -> fluid.uiOptions.settingsPanels > fluid.uiEnhancer.defaultActions -> fluid.uiOptions.actions > > These could be further subdivided as needed, (e.g. > fluid.uiOptions.textSettingsPanels, fluid.uiEnhancer.textActions). > > > I haven't yet come up with any suggestions for renaming > fluid.uiOptions.defaultModel and fluid.uiOptions.defaultModel.outOfTheBox, > but do have some questions about them. > > 1) Do we really need fluid.uiOptions.defaultModel as a grade? It appears to > only set an empty defaultModel as a member. If one was to override this, as > illustrated by fluid.uiOptions.defaultModel.outOfTheBox, you'd have to > basically rewrite all of the configuration anyways. The only difference is > the gradeName "fluid.uiOptions.defaultModel" vs "fluid.littleComponent". > > 2) Why don't we use "fluid.uiOptions.defaultModel.outOfTheBox" as a grade of > what is currently called fluid.uiOptions.defaultSetttingsPanels and > fluid.uiEnhancer.defaultActions, instead of including it along side those? > > Thanks > Justin > > On 2013-06-03, at 2:01 PM, Justin Obara <[email protected]> wrote: > >> Looking forward to chatting about this in the channel today, but I'll add my >> current thoughts here just in case. >> >> I think I'm in agreement with not using the word "default" for the >> "outOThefBox" configuration. I was a bit leery about this as I helped >> implement it, and should have put more thought into it at the time. As with >> the rest of our naming, I think we need something descriptive about what >> exactly it is that a user could expect from it. What makes this set >> different from some set that other parties might create? For that matter >> would we ever consider creating multiple sets ourselves? For example, one >> that included only the legacy options and one that also included new >> settings like "content simplification"? >> >> I'm also not sold on fluid.uiOptions.defaultModel as a component/gradeName. >> When first reading that I would assume that it is itself the default model, >> but that is actually at fluid.uiOptions.defaultModel.defaultModel. >> >> The word "defaults" is already associated with a component's "default" >> configuration as specified in a call to fluid.defaults. If we call too many >> things "defaults" it will make things increasingly confused. I think we >> should try to refrain from using this word where possible. >> >> Thanks >> Justin >> >> >> On 2013-06-03, at 2:49 AM, Antranig Basman <[email protected]> >> wrote: >> >>> On 23/05/2013 13:17, Cheetham, Anastasia wrote: >>>> >>>> Antranig, this is an interesting topic. Naming can be a tricky thing; >>>> thinking about the issues you raise >>>> has really got me pondering. >>>> >>>> Here are some stream-of-conciousness thoughts: Some opinions, some >>>> musings, some questions… >>>> >>>> >>>> First, Antranig, some of the points in your email brought to mind the >>>> discussions started in the thread >>>> "Designing a new UIO API." In that thread, you pointed out that we don't >>>> want to somehow elevate the >>>> out-of-the-box set of panels and settings to any privileged status. You >>>> also said >>>> >>>>> We anticipate that in real life, almost ALL practical uses of UIO will be >>>>> in the scenarios labelled >>>>> under the headings "adding settings" and "removing settings". >>>> >>>> These points make a lot of sense to me. Combine them with the information >>>> in this email, and it seems >>>> that the natural, un-altered state of the components is: empty. I'm >>>> inclined to refer to the "natural, >>>> un-altered state of the components" as the "default" state. >>>> >>>> But if we use "default" in our naming of the empty components, how then do >>>> we refer to the set of >>>> out-of-the-box panels and settings? "outOfTheBox"? "builtIn"? "starter"? >>>> "basic"? >>>> >>>> Should we even be referring to them as a set at all? Correct me if I'm >>>> wrong, but I imagine there will be >>>> use-cases where integrators might want to use *some* of the out-of-the-box >>>> settings but not others. >>>> Perhaps there should be no single grade that adds all of them, but rather >>>> separate grades for each? >>>> (Personally, I think we *should* have a single grade that adds all the >>>> out-of-the-box settings in one go >>>> – and not require six separate grades – but I could probably be convinced >>>> otherwise by good arguments.) >>> >>> Thanks for these remarks, Anastasia. In answer to the last questions - we >>> don't have an alternative to have names for the separate grades as well as >>> the since grade which combine them for user convenience. If the separate >>> grades didn't have names, they couldn't exist :) "outOfTheBox" seems to be >>> our current de facto alternative to "default", and I think words like >>> "builtIn" are prejudicial by virtue of the previous argument suggesting >>> "privilege for the 1st parties" - clearly these grades are NOT actually >>> "built in" as we established. >>> >>> I'm not particularly excited about any of the words on offer, so calling on >>> the community for some fresh brainstorming! Perhaps we can have a chat in >>> IRC tomorrow - >>> >>> Cheers, >>> A >>> >>> _______________________________________________________ >>> fluid-work mailing list - [email protected] >>> To unsubscribe, change settings or access archives, >>> see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work >> > _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
