Is there an existing library that automatically creates a Java Swing form from a Properties (or Properties-like) object? i.e. shows 2 columns, as many rows as there are properties, properly justified Property names on the left, JTextFields for the values on the right.
I do not have access to the property names (or expected types) at compile time.
In addition, the solution must allow some value fields to be set read-only after construction.
A great solution would :
allow some property values to be specified as sensitive, requiring a JPasswordField
provide input format checking, e.g. against an object type (such as URL, Double, etc)
or by type-sensitive so that appropriate widgets (or buttons to bring up appropriate widgets) are used instead of JTextField for standard object types. e.g. JFileChooser for properties expected to be of a File type, SwingX Colour/Date selection, numerical format checking)
Getting into type-specific properties starts to sound like JavaBeans. I'd rather not go down the JavaBeans route unless there is a really easy - not a big framework - solution for this for an object that is a Javabean.
(I already know how to manually do this and could write a simple implementation myself that ignores sensitivity/type information - anyone answering along those lines will be shot down! I only want to know if such a beast already exists, preferably in a well maintained library)
UPDATE: related to Java Beans - creating an inspector window
No such thing exists. However, I wrote a rudimentary feature (and released it OSS) for https://github.com/fommil/zibaldone
We use JIDE, which not open-source.
If you don't mind that, take their Property Grid for a spin - it seem to match all your requirements.
Related
I'm working on an application that has a huge list of key value pairs in multiple languages and I'm using the Eclipse RCP model with NLS.
For anyone unfamiliar with this, you have multiple properties files in different languages and the framework generates classes full of static strings for the current language.
Thus I can have I18NMessageTooltip.Cancel that provides a tooltip for the cancel button, in the currently selected language, whatever it may be. Same for labels and many other things.
The problem is, the same translation properties files have a great many things that I need to search trough.
As a stop gap, I made a search using reflection, but that is, in my opinion, quite inelegant.
Is there any other way to search through I18N static fields, other than either:
a. Reflection
b. Reinventing the wheel and searching through the properties files by hand
We have a rather large application, with a great deal of dynamic content. Is there anyway to force struts to use a database for the i18n lookups, instead of properties files?
I'd be open for other ways to solve this as well, if anyone has ever done i18n with dynamic content.
I don't know of an easy plug-and-play solution for this, so you will probably have to implement it yourself -- plan on spending quite a bit of time just coming to grips with how the localization features of struts 2 (and XWork) are implemented. The key will probably be to provide your own implementation of com.opensymphony.xwork2.TextProvider (and tell struts to use it by providing a <bean> tag in struts.xml). I can think of at least two ways of fitting this into the overall architecture:
Have your TextProvider implementation access the database directly. In the spirit of YAGNI, this is probably the best way to start (you can always refactor later, if necessary).
Alternatively, you could place the database code into an implementation of Java's ResourceBundle interface, which is what XWork uses internally. To me this sounds like an even more design-heavy approach, but on the plus side there are some articles around describing how to do this.
No, there is no built-in way to have Struts2 load localized content from a database. You would need to write that yourself.
What are your requirements? Do you need for users to be able to dynamically change field prompts, error messages, etc.?
You may be able to do something like that by building a custom interceptor. You could have the interceptor read all the key value pairs from your database and inject them into the value stack. The only thing I am not sure about, not really having messed with i18n with struts before, is if the i18n stuff pulls that information from the value stack. If not, I am not sure if maybe you could do something else in the interceptor to load up the information.
Building a custom interceptor is not too terribly complicated. There are plenty of tutorial sites out there, including (brace for self promotion here) my blog: http://ddubbya.blogspot.com/2011/01/creating-custom-struts2-interceptors.html.
Use properties files just for static content, like labels, messages etc.
For dynamic content start with a database table that includes a language-code-id for every language you want to use. All the dynamic content entries that are already translated go with their respective language-code-id added to their primary key. If a translation is missing, you can program your application to fall back to your default language in order to make things easier until the right translation is present.
Let your users provide their contributions in the language they like and store it with the appropriate language-id. Someone should provide the translation to the other languages in order to make the contribution complete.
...
PRIMARY KEY (`subject_id`,`language_id`),
...
Today I will have question regarding formatting numbers in Tapestry5 grid.
I have couple of fields in Grid component that I need to format due to some rules that concerns decimal mark and thousands separator. For textfields I'm using translator defined for whole application (like in this example) but I have no idea how to get same functionality for grid (or even if it is possible at all).I would like to have same mechanism available for all grids in my whole applications.
Of course not all numeric grid field will be currencies so there should be some kind of possibility to configure them.
I know that with grid I can use ValueEncoder but I think that this won't work in that case because it encodes whole object displayed in grid, not only some defined fields.
One more thing: I know that I can define each field to get value from method and there do all functionality, but I'm looking for something more flexible - like mentioned earlier "translator" for textfields.
This can be done by the combination of a few things
A DataTypeAnalyzer which produces a String datatype given a PropertyAdapter
A DisplayBlockContribution which maps the datatype to a block (see also EditBlockContribution).
Contribute the DisplayBlockContribution to the BeanBlockSource
Note that this will not only affect the grid, it will also affect all bean based components (eg BeanDisplay).
Jumpstart example here
You can override the default grid cell rendering behaviour by defining a block property named xCell (where x is the column name). The documentation gives an example of customising rendering of the lastName column.
<t:grid source="users" row="user">
<p:lastNameCell>
<t:pagelink page="user/view" context="user.id">${user.lastname}</t:pagelink>
</p:lastNameCell>
</t:grid>
I'm developing an application to my software engineering class and one of the requisites is that it has 2 or more languages in the interface. I already implemented that. On the other hand, it is required that the user can change the language on its own will by choosing from a combobox or something like that.
As i'm using AWT and Netbeans, I can't edit the initComponents method of the form, as it is automatically generated. I have the option below in mind, but don't know if they would even work, so I'm asking for help.
-Edit the constructor of my class so that it looks like this:
public JFmyConstructor() {
initComponents(); //auto-generated
myInitMethod();
}
The problem I think i'm going to find is that I need to call the constructor one time after the interface is already running (and thus, all objects instantiated. Is there a workaround for this?
Probably my answer comes a little late (too bad you put wrong title)...
Obviously you do not have to call any constructor in order to switch language at runtime. In Java Desktop applications it is as ease as:
Locale brazilian = new Locale("pt", "BR");
Locale.setDefault(brazilian);
Of course if you want to switch it via JComboBox, you would probably do it a bit different. What I would do, I would actually create Model (Swing promotes MVC Design Pattern) that will hold data (different Locales) and I would set default Locale in correct ActionListener. It is not easy though.
Of course I would rather use native names for Locales. If you have them constructed, you can easily get native name Locale name by simply calling getDisplayName() passing itself as a parameter:
String brazilianNativeName = brazilian.getDisplayName(brazilian);
The result might be unsatisfactory for certain Locales (I believe Brazilian Portuguese is unfortunately one of them), but there is not much you can do about it (unless you use your own string).
To be honest, for just two languages, I would probably use some links instead. You can use simple JLabels to do that, just set correct font properties and color and assign common ActionListener. You can then query which one was actually clicked and create and set Locale appropriately. For homework that should be sufficient.
SWT and NetBeans is a weird combination. If you can do things the "normal" way with SWT and use Eclipse, then there's a powerful set of tools for managing localization, all built right in. See, for example, this introduction.
The best way is to use resource injection for all components (rather than getting i18n strings from a Bundle at panel construction time).
Resource Injection is available in a number of open source libraries or frameworks.
Since you use NetBeans, you should be able to generate an application based on Swing Application Framework (SAF), which already supports Resource Injection.
Otherwise, there are also libraries out there that do just that; simply google for "swing" "resource injection" and you'll find, e.g. Fuse library.
Edit:
You should also take a look at this SO question that deals exactly with the same problem, and which has more detailed answers (including my own).
I can understand using properties for messages and international settings but I feel there has to be a better way to get specific parameters of a program like background color, resolution, floating point numbers, etc.
Every time I load a set of properties I have to have a wrapper class to convert all those into something meaningful to my program. Say I want to load a color, I have to read the color as a string and then convert it to a color in my program. Everything in a property is a string. So numbers have to get converted too.
I feel like there should be some sortof of library that can detect(or maybe it's specified in the file) what it is and you would automatically get the correct data type when you load it in.
Is there anything like this? Thanks.
You could use XMLEncoder/XMLDecoder. They are text-based serialize alternatives for java beans.
As KitsuneYMG mentioned, you can use an XML deserializer to more easily handle the unmarshalling of configurable, typed values; XStream is an excellent library to simplify the object field mapping process. Also consider the YAML and JSON serialization formats as alternatives to XML, they are more concise and potentially easier to manage and both have fine Java bindings.
Moreover, by accessing these configurable objects via the Factory pattern you can have better control for loading special cases (such as automated tests) as well as XML documents from the filesystem or classloader resources.
Why is there no reference on the preference api? I believe using XmlEncoder or any other serialization mechanism is a round about way of doing it. I use java preference api for storing custom application specific info. The only problem was there is no default putObject and getObject method.But there is a good workaround. See this link for on how to store objects in preference.