Recently while developing a swing application somebody told me to use (ComponentClassName) Beans.instantiate(MyClass.class.getClassLoader(), ComponentClassName.class.getName()) to create component object instead of using "new". I would like to know the right approach.
You can use Beans.instantiate() if the type you want to instantiate is chosen dynamically. Generally the new keyword works just fine, and is what I always use in Swing applications.
I think the right approach will be to use the new keyword, after all, that's it's role. The way you are using Beans seems a bit forced since you know what type of class you wish to instantiate. Second, since this is a swing application, most probably you are using default swing classes (maybe extending some of them). Another problem with this approach is that you must have a constructor without args in your class.
Class.forName() can be used for the same thing as the code above, but if you don't want to dynamically create a class at runtime, stick with the new keyword.
Related
I want a source component to produce an agent with source.inject() , but I have to call this method from a foreign Java class at the projects sidebar on the left. I am new to Anylogic and I don't have much programming experience. I don't know how I can correctly refrence the source.
Your Java class ("in the side bar") needs to have a private field myMain of type Main. In its constructor, add that field as an argument and fill it as usual with Java.
When you initialize an instance of your class, provide it main as well (depends on where in your model you initialize).
If this sounds like gibberish, I strongly suggest you take a step back, learn more advanced OOP, Java and how AnyLogic applies that :)
i was wondering if their is any way to dynamically create a static field for a class during run-time using reflection or a related API. If needed i can use the java native interface to accomplish this task if someone could tell me the appropriate steps. I don't want to use any data structures such as a hash-map, as i am doing this completely for fun. Please don't suggest using maps as i am not using this for any real program this is a completely theoretical situation. Thanks.
You could do this during class load time using bytecode manipulation.
This is a very complex solution though, so I'd consider other options.
It also does not help too much to have a new field that is not known at compile-time, because you cannot compile anything against it. If you are going to use reflection to access it, you might as well use a Map in the first place.
Java doesn't support metaprogramming or runtime programming in a way that is particularly nice or effective.
You could use a decorator pattern. You could pass the object that you want to add a static field to into a wrapper object. This wrapper would have the static field and the calls to the wrapper object would relate to the wrapped object.
If you could provide more details about the functionality you're looking for I could try to provide a better solution. You might be better off looking into another language that does support runtime programming if you absolutely need it to be done in that way.
So, yeah. That. I'm going through the tutorial one step at a time, so if the answer comes up later, forgive me. It's step 1 in this section.
I understand the ease of using this to have access in other methods in the EntryPoint class, but coming from the Spring MVC world, this sort of thing might be thought of as a controller and be a singleton (bean). Is it wrong to think this way in the GWT world?
With GWT you are coding as if it was a desktop AWT program. So, you do not have CDI or anything similar.
So, if you put all your information in a bean, you still would have to either:
keep a bean attribute in the class
pass it as a parameter in the method call
to get a reference to it (instead of retrieving it from CDI when needed)
While you can still use a bean when needed, these attributes are closely linked to the main class (in fact they are other graphical components to show). In general, I would only use bean when you have a bunch of attributes that are tightly coupled between them but are not tightly coupled to any other class.
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'm writing a small application in RCP to wrap around the business logic in another (non-RCP) simulation library. I can access and use the library fine from any of my plugins, but I don't know where I should put the instance of the Simulation library so that, say, one of the command handlers can make calls to it.
From reading the docs it sounds like I should be storing 'global' information like this in the workbench - but I still don't really understand how to do that.
Help?
First, the business layer (BL) can and should reside in its' own plugin. That will provide decent decoupling between the layers.
Second, you should carefully decide what the interface should be and which classes are exposed. Ideally, you should mostly expose interfaces and data objects.
Finally, decide how the "hand shake" works. E.g., how to obtain the initial interface to the BL. Since it is a Plugin, it could have an Activator which loads it. You could add a method in the activator which returns the BL interface.
If you are looking for something more decoupled, you could create an extension point or deploy the BL as an OSGi service, but that's a bit of an overkill for you need.
If I understand you correctly, I see two ways:
Store the instance in the model plug-in itself, using ‘SimulationFactory.getInstance(String myAppId)‘. The passed String is a constant in you app that is always used, when obtaining the reference.
Define a new class e.g. GlobalAccess in you app that is initilized with an instance of your model and has some getter (whether you use a single instance again or only provide public static methods is a matter of taste).
The seocond way is similar to some classes in eclipse like platfom or platformui, where you can obtain initial references and navigate through the workbench.
edit
i just found a tutorial that might help you:
Passing Data between Plug-ins