+1 for starter On 2013-06-05, at 5:01 PM, "Zenevich, Yura" <[email protected]> wrote:
> 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 > > <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
