I would think the most efficient mechanism for supporting runtime locale
changes would be to create a data class around the resourceManager
something like this:
Class ResourceModel extends EventDispatcher
{
Private var _myResourceName:String;
[Bindable("localeChanged")]
Public function get myResourceName():String
{
Return _myResourceName;
}
Private var _myOtherResourceName:String;
[Bindable("localeChanged")]
Public function get myOtherResourceName():String
{
Return _myOtherResourceName;
}
}
And on a locale change, code would stuff all of the "_" private variables
and dispatch a single localeChanged event. Binding to functions is heavy.
FlexJS has some optimizations for binding to properties.
Even faster, but potentially more dangerous is to have components register
themselves with a central facility that will push new strings to the
component if a locale changes. Of course that would have to deal with
unregistering things that go away and things registering after the locale
change.
-Alex
On 2/13/14 4:36 AM, "Cosma Colanicchia" <cosma...@gmail.com> wrote:
>Just a random thought: I never used the @Resource directive, because it
>does not allow locale change at runtime, so I end up in lots of ugly
>text=³{resourceManager.getString(ŒmyBundleName¹, Œmy.resource.name¹)}²
>that
>does not help code readability.
>
>Maybe we could improve it? I¹ll just throw some ideas from my experience:
>
>1) compiler argument to enable runtime locale change support (maybe we can
>find a light-weight manner to implement it, compared to the mass of event
>listeners generated now towards the ResourceManager for .getString
>bindings)
>
>2) short-hand syntax alternatives, such as:
> - text=³@Resource(Œmy.resource.name¹)² (omit bundle, search in all
>bundles)
> - text=³@R(...)² (directive alias *)
>
>3) support runtimeResourceProvider, similare to runtimeDPIProvider (e.g.
>to
>allow runtime logging of missing resources)
>
>4) compiler argument to enable compile-time resource bundle checking,
>generating warnings when invalid @Resources directive are used (not found
>in compiled bundles)
>
>5) compiler argument to enable output of resources report, listing all
>@Resource usages found by compiler in an XML file (similar to
>-link-report), this could enable external, manual or automatic review of
>resource usages (would be verify useful in complex projects where
>resources
>are loaded at runtime from an external source)
>
>
>* Directive alias support could be a nice feature on its own.. being able
>to use @E for @Embed, @R for @Resource etc. could help keeping complex
>MXML
>concise and readable..
>
>I actually don¹t know when I will have the cycle to dig into the compiler
>code and see if its doable, but I still would like to have some feedback
>on
>this...
