etf
|
Posted: September 05, 2009 22:18 by etf
|
Primary goals of the release:
Early access release is available for downloads. http://kenai.com/projects/bsaf/downloads/directory/Releases/1.9/EA Release notes: http://kenai.com/projects/bsaf/pages/190EA |
1.9 Release
6 posts
Replies: 5 - Last Post: October 21, 2009 15:16
by: etf
by: etf
showing 1 - 6 of 6
robross
|
Posted: October 20, 2009 09:24 by robross
|
|
How important is backwards compatibility going forward? I can understand wanting to just fix some bugs and clean things up with the existing code base, but I think having to keep compatibility is going to seriously hamper any attempts to improve the overall design of this framework. 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. I could probably fold these changes into the existing appFramework structure, but many things I want to do will break existing apps - but it will end up being a better framework in the end. So I can help out a little bit here, until my needs diverge from the SAF design and I'll continue on my own code base. Rob |
|
etf
|
Posted: October 20, 2009 21:34 by etf
|
|
Thank you for your interest in this project! First of all lets be honest, it's not a framework. It's just a early stage prototype which works and has great potential in spite of messy code. As I have stated before, I want to keep it lightweight and easy to use. As for backward compatibility it is a nice-to-have feature. We could change architecture and even API until we could provide clear migration steps. I really like you ideas. It would be great if will be able to join our forces. Better Swing Application Framework is our primary target. I propose to discuss API enhancements in a separated thread and (may be) create a new experimental branch for further development. |
|
etf
|
Posted: October 21, 2009 15:16 by etf
|
|
SAF is a dead project and I don't like mailing lists. I would propose this forum or Wiki. Actually, wiki engine on this portal is poor. Thus, the best choice would be wiki - for ideas/API documentation and forum for discussion. I have created a new page for you - http://kenai.com/projects/bsaf/pages/Resource_map Please create a new topic in the forum for further discussion. |
showing 1 - 6 of 6
Replies: 5 - Last Post: October 21, 2009 15:16
by: etf
by: etf
