Metadata
- Source
- FLUID-5180
- Type
- Improvement
- Priority
- Major
- Status
- Closed
- Resolution
- Fixed
- Assignee
- Justin Obara
- Reporter
- Justin Obara
- Created
2013-10-15T15:06:56.747-0400 - Updated
2019-09-23T08:35:09.848-0400 - Versions
- N/A
- Fixed Versions
-
- 1.5
- Component
-
- Prefs Framework
- UI Options
Description
Currently the preference framework makes use of message bundles and the messageResolver. In cases where the renderer is used, it is simple enough to use the message rendererer component to get at the values. However, if a component needs to use the string values outside of the message renderer component, expanders are needed to perform the appropriate lookup.
Example:
// simple lookup function
fluid.slidingPanel.lookupMsg = function (messageResolver, value) {
var looked = messageResolver.lookup([value]);
return looked ? looked.template : looked;
};
// complex lookup function which returns an array of strings for a given group of messagekeys
fluid.prefs.panels.lookupMsg = function (messageResolver, prefix, values) {
var messages = [];
fluid.each(values, function (value, key) {
var looked = messageResolver.lookup([prefix + "." + value]);
messages.push(looked ? looked.template : looked);
});
return messages;
};
This process should be simplified through the use of resolvePathSegment, similar to how the dom binder works with calls to "{that}.dom.selector"
1) Create an object to lookup the messages from the message resolver. and bound to the stringBundle member name.
2) the function should be able to look up keys and namespaces.
Note this will only provide access to the string value via IoC.
Comments
-
Justin Obara commented
2013-10-15T15:08:12.898-0400 Discussion in http://wiki.fluidproject.org/display/fluid/fluid-work+IRC+Logs-2013-10-15
-
Justin Obara commented
2013-10-16T09:43:43.257-0400 The above strategy has issues when dealing with prefixed message keys. For example the ones used in contrast https://github.com/fluid-project/infusion/blob/master/src/framework/preferences/messages/contrast.json
These are prefixed because they correspond to messages that should be used in an array of strings.
-
Antranig Basman commented
2013-10-16T15:11:03.176-0400 Hi Justin - I suggest you adopt a different prefixing character for your strings, for example the hyphen "-" that we use in our CSS class names. Even if we were to adopt the escaping parser for these EL expressions, it would mean an unsightly and confusing escaping of your existing prefixes as for example contrast\.bw etc.
-
Justin Obara commented
2013-10-17T13:19:17.837-0400 Antranig, I took your suggestion and changed the prefix to "-" so now we would have something like "contrast-wb".
However I'm having trouble with the IoC resolution. If I try to resolve the values in the strings block, I get an error that the messageResolver doesn't exist. If I try to resolve it in the protoTree, I'm getting the string literal instead of the expanded value. (for optionnames).
http://pastie.org/private/hudscqyg1vl5zp59smlw -
Justin Obara commented
2013-10-18T13:11:56.706-0400 Submitted pull request https://github.com/fluid-project/infusion/pull/419
-
Justin Obara commented
2013-10-28T08:49:29.606-0400 pull request merged at 861d635d56c7546c764d23cf40e7f96e85516b17