I went ahead and wrote a tool for our project to perform resource generation for our project, and used it to generate image and string resources for one of our applications.
Kevin Wright said: > The actual code generation will be a trivial "7 lines in your favourite > scripting language" sort of affair, so let's call it 20-30 lines in Java > (i.e. still not exactly massive). My solution is about 130 lines of Java, plus a 20 line java source template, and it handles internationalizable strings as well as images. It doesn't auto-scan for changes and regenate (I have to double click to launch a script), but that didn't make it much less useful, and that feature could be added later (maybe sbt be good at auto-scan). It still helped me identify unused images and text in my project and guarantees that references strings and images won't be missing at runtime. Fabrizio Giudici said: >So, if somebody is going to do that, please use a special Key<T> object which >would avoid casts. My implementation only handles Strings and BufferedImages which are eagerly loaded with the correct types. Reinier Zwitserloot said: > I doubt this would take you more than a single man-day of work, including > testing. It took me about 1.75 hours to implement this, and use it to load images and strings for one of our projects, and to use it to internationalize the project. Casper Bang said: > So why it hasn't been done already? After working on this, I think it is successful in Android because they were able to choose a standard convention for where/how resources go and how they are loaded, and they provided the tool set so that it works right out of the box. My project uses its own (different) standard--I'm guessing there is more standardization with maven-like conventions, but other projects may have different conventions, which would inhibit the universality of a J2SE tool like this (or maybe encourage standardization on maven-like convention). Anyways, since our project uses an unconventional way of storing and loading resources, this may be of limited reusability for others, but in case you are interested, you can view my solution in our repository: Resource generator: http://goo.gl/QDNxG Example generated file: http://goo.gl/k8qNI The repository is not fully public so to log in or checkout you have to use username and password = guest Some outstanding issues with my particular implementation: 1. String and image names may collide--we'll probably have to handle that at some point. Maybe I will split them into separate generated java source files, or prefix images fields with "IMAGE_" (that wouldn't guarantee collision-free fields, just increase the probability). 2. My implementation doesn't yet handle substructure in images directory 3. No good support yet for for strings that have to be formatted with MessageFormatter 4. No support for audio yet or other resource types. Thanks for your comments and ideas! Sam -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
