Tuesday, May 30, 2017, 5:00:00 PM, Woonsan Ko wrote:
> On Sun, May 28, 2017 at 4:29 PM, Daniel Dekany <[email protected]> wrote:
>> In FM2 we have these things called custom attributes, which are
>> unrestricted key-value pairs that the user can associate on all 3
>> configuration scopes: Configuration, Template, and Environment. The
>> key can be anything, like an enum or a String.
>>
>> In FM3, when earlier I have refactored it to use immutable
>> configuration in all 3 layers, I ran into a problem; in FM2 custom
>> attributes are mutable anytime in all scopes by design. That's because
>> one application of them was holding scoped custom state variables. So
>> much earlier, I have removed that functionality from attributes, made
>> the Map of attributes immutable as FM3 demands it, and to fulfill the
>> lost functionality I have added a new interface called
>> CustomStateScope and all scopes implement that.
>>
>> So now that custom attributes doesn't server that use case anymore, we
>> probably should rename custom attributes to custom settings. They are
>> pretty much like the other configuration settings now (i.e., they are
>> only mutable in builder classes an in Environment), except that they
>> are defined dynamically (using a Map) by the user. Apart from the
>> name, the behavior of the API would mirror that too, that is, as for
>> all settings we have setXxx(value)/getXxx()/isXxxSet() methods with
>> the documented semantics, similarly we will have setCustomSetting(key,
>> value)/getCustomSetting(key)/isCustomSettingSet(key) methods. The
>> `key` parameter is needed as we can't have the name of the custom
>> attributes in the method names (i.e. in place of the Xxx). BTW, the
>> `key` is Serializable so that it can be stored in Exception-s. (I
>> wonder if it should be String... but I guess using enum-s for keys is
>> more efficient, so I don't want to remove that possibility.)
>>
>> Anyone opposes this?
>
> No objection! All sound like a plan to me!
Done. This also means that instead of
<#ftl attributes={ 'a': 1, 'b': 2 }>
now we have
<#ftl customSettings={ 'a': 1, 'b': 2 }>
But I hope this will change further later... I think that custom
settings that are identified with a String key (i.e, a name) should be
enforced to chose a key that differs from core setting names. For
example be having a dotted or coloned name like
"myframework.mySetting" or "myframework:mySetting" (standard setting
names doesn't have such punctuation). And then you can write <#ftl
myframework\.mySetting=123> and we don't need a customSetting
parameter. But, that's for (much) later. For now the point is
polishing the configuration API-s and proceed...
> Regards,
>
> Woonsan
>
>>
>> --
>> Thanks,
>> Daniel Dekany
>>
>
--
Thanks,
Daniel Dekany
