Last updated October 24, 2009 04:39, by robross
Feedicon  

BSAF-35

I've started implementing my own framework, and I started by rewriting the ResourceMap and ResourceConverters to make them extensible and pluggable, in addition to enhancing ResourceMap functionality:

1. Resources are cached by key and converted type, so the same resource may be accessed in different contexts, perhaps as a String in one case, a Point in another, etc. Unlike the current framework where the first time you get a resource, you convert it to that type and if you ever refer to it as a different type you get an error.

2. All ResourceConverters are public and extensible, and have a simple API. ResoureMap getters all take a ConverterRegistry parameter that lets you supply your own converters; or you can set the ConverterRegistry on a ResourceMap to your own custom version.

3. I added a few converters to round out the existing offerings, Rectangle2D.Float/Double, BufferedImage, Point2D.Float/Double, etc.

4. Any resource can be converted as an array of primitive types, or arrays of any type for which there is a converter. So you can convert a resource like "fooKey = one, two, three " as a String[], or "fooPoints = 1,2 ; 3, 4" -> Point[], etc.

5. Variable substitution using ${} is enhanced, supporting nested expressions, and it will also check the System.properties for a value if the key is not found in the ResourceMap.

6. The concept of being able to load multiple bundles into a single ResourceMap is a great idea and I've kept that. But the need to explicitly name the additional bundles for the constructor seems like a speed-bump in the process. If you have a one-to-one mapping between a class and its ResourceBundle, it's trivial to automate loading that bundle. But if you want to break up your bundle into multiple files, perhaps one for all your error dialogs, one for all your Action properties, etc, then you'd have to remember to include those additional files and manually call the correct ResourceManager/ResourceMap constructor. So what I have done is implement the ability to include a special resource key, "import", that takes as a value a comma-delimited list of bundle names. These will be loaded in priority order, just like the current ResourceMap constructor does. I.e, if you have "import = Bar, Baz" in your FooClass.properties bundle, then Foo.properties, Bar.properties, and Baz.properties all get loaded into the same ResourceMap. Properties in FooClass shadow properties in Bar, which shadow properties in Baz. It makes sense to me to reference these additional prop files into your main prop file, since at the time you are working with your properties, you are contextually in the same "area", and it should be easy to capture that information at that time, rather than remember to create the right constructor argument in some other area of the code.

7. I added a setLocale method. This will propagate the Locale change to the entire ResourceMap chain. It also fires a property change event for the "locale" property. Longer term I envision automatically adding PropertyChangeListeners for this property on any configured components that use resource values, so they can automatically change their display state when a ResourceMap locale changes.

  • Mysql
  • Glassfish
  • Jruby
  • Rails
  • Nblogo
Terms of Use; Privacy Policy;
© 2013, Oracle Corporation and/or its affiliates
(revision 20140418.2d69abc)
 
 
Close
loading
Please Confirm
Close