Just to clarify, I was thinking of using |starter|. Please let me know if you think |basic| might work better
Cheers On 2013-06-05, at 4:28 PM, "Zenevich, Yura" <[email protected]> wrote: > 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 _______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://lists.idrc.ocad.ca/mailman/listinfo/fluid-work
