incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Om <bigosma...@gmail.com>
Subject Re: Asset / i18n resource management improvements
Date Tue, 12 Jun 2012 22:39:11 GMT
>
> To me, the most important thing to get right is the run-time
> implementation.
> Once we nail that, someone will figure out how to get you something like
> code-hinting.
>

Just to be clear, the benefit is not only code-hinting, it is also compile
time error checking.  If a key does not appear in autocomplete and the user
goes ahead and tries to use it, there will a warning/error generated
depending on how we want to implement it.  It will also be useful during
refactoring of code.

Fundamentally, IMO, a string-only resource system is a simple lookup table
> of a string key to a longer string.  Then for organizational purposes folks
> tend to group those keys into bundles.
>
> What we do today is bake classes for these bundles.  Then we install these
> classes into a manager at startup time.  And we do that for error strings
> you may never see, and Alert labels you hopefully will not see before the
> first screen appears.  And the classes are actually quite big compared to
> simply embedding a string table in the SWF (or loading the string table at
> runtime).   Also, it isn't clear you need a class.  You might be able to
> use
> simple dynamic objects instead.
>
>
Yes, we do bake classes for these bundles but still, the implementation is
such that it is useless for autocompletion and compile time checks.  From
the docs[1], here is the generated class for a resource bundle in the
current implementation:

public class RegistrationForm_properties extends ResourceBundle {
    override protected function getContent():Object {
        var properties:Object = {};
        properties["registration_button"] = "Registration";
        properties["submit_button"] = "Submit Form";
        properties["personname"] = "Name";
        .
        .
        .
        return properties;
    }
}

The new way would be something like (Dirk, please correct me if I am off here) :

public class RegistrationForm_properties {
        public static var registration_button:String = "Registration";
        public static var submit_button:String = "Submit Form";
        public static var personname:String = "Name";
        .
        .
        .
    }
}

Runtime overhead wise, the second implementation will be a bit lesser
because we
dont use the generic object or any do any dynamic key lookup.


And the classes are actually quite big compared to
>  simply embedding a string table in the SWF (or loading the string table at
> runtime).   Also, it isn't clear you need a class.  You might be able to
> use
> simple dynamic objects instead.
>
> And if we decide that classes have too much overhead and simply use dynamic
> objects, what would then happen to code hinting?  There wouldn't be any
> classes to hint.  How would you find spelling errors in the keys?  I'd hate
> to see us drag down runtime performance just so you can get code-hinting.


I dont think we should use dynamic classes at all.  Which is kind of
what happens today.  It causes poor runtime

performance and it does not help in compile time.

I think some IDE will someday be smart enough to look at the string tables
> and help you get your keys right.
>

But it wont generate compiler errors/warnings for missing keys or
wrong key usage.

[1] http://help.adobe.com/en_US/flex/using/WS2db454920e96a9e51e63e3d11c0bf69084-7f2d.html#WS2db454920e96a9e51e63e3d11c0bf69084-7f34

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message