Improving @Resource MXML directive

[Cosma Colanicchia <co...@gmail.com>]

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...

Re: Improving @Resource MXML directive

[Alex Harui <ah...@adobe.com>]

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" <co...@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...