So I'm having one super class, Block, that extends Composite and uses the UIBinder to make the layout
class Block extends Composite
I want to create two subclasses for that one, that each have different set of icons that have to be added. For example an InactiveBlock and an ActiveBlock.
My problem here is that I want the layout of both blocks (the icons, and some buttons,labels) to be made through the UIBinder aswell, and then to add that UIBinder (and it's events) to be added to the main Block.
Obviously I can't do something like
class ActiveBlock extends Block, Composite
add(initWidget(UIBinder.create(this)));
How could I accomplish this?
(ps if my question is not clear enough, please do tell so I can elaborate)
I would make it a single class with a constructor method having boolean as an input parameter (active/inactive).
So you can define all the common fields and methods in the class, like event handlers, images, etc.
And then use the constructor method to add the elements and handlers to the basic widget. Something will be added to all instances, something depending on whether it's active or not.
In this case you won't end up with duplicated code, still will have a benefit of using uibinder, and eventually your code will be simple enough for reading.
Related
I have a panel, let's call it detailsPanel, which holds a Person reference and displays its field values in the following manner:
Name: person.getName ();
Surname: person.getSurname ();
Emain: person.getEmail ();
.... .......
.... .......
And so on. I will use JLabels (correctly aligned using a GridBagLayout) to show each (fieldName, fieldValue). I have a lot of fields to display.
The problem is that the panel which shows the details must be always visible, i.e it will not be shown in a modal JDialog, so that i could create the panel by simply reading my Person object fields at the panel creation.
The panel must always be visible, and its Person reference will change when the user selects a different row in a Person list. This means i will call a method to update its state, something like:
detailsPanel.setPerson (aPerson);
Now, i'm wondering how i should update all the fields. Should i keep a reference to all the JLabels which show the values, and use setText(value) on each of them when i update the panel, or would it be better to override getText() method for every label, returning the correct field value, so that in the update method i would only repaint the panel, and the text would automatically change when the getter method is used on a different Person object?
Any suggestion is appreciated!
Since this is UI stuff which is usually called almost never (relative to how often things are called in other computation) you don't need to worry about efficiency at all. Just do what you think is the most elegant solution. There are three options That quickly come to my mind. They are ordered from quick and static to elegant and reusable:
Quick and dirty: create your constructor and make everything look nice. Then move everything from the constructor to a separate init() method and every time the entities change, you just call removeAll(); and then init() again.
As you suggested, keep a reference to all labels and use the setPerson() method to update all panels. Then call this method in the constructor (this is arguably the most common solution).
As you suggested, build your own extension of JLabel. This new class should either have an update() method which is to be called when things change, or have it set its own listeners to ensure that it gets notified of any relevant change.
If you are planning to create a single panel which is supposed to display all kinds of objects, you could have those object implement an interface called Displayable which gives you generic access to all its values and maybe even listeners to each value. An alternative to the Displayable interface is to use reflection and use annotations to allow the panel to get its values for display.
Please note that the most elegant solution is - contrary to what some people may tell you - not always the best for any situation. How much maintenance do you expect there to be in the future? How big is the application? Will you ever hand off the code to someone else? All these and more need to be considered to decide how "nice" you want your solution to be.
I'm making a button class that handles input and drawing by itself; the only thing that needs to be defined is the location and what happens when the button is pressed.
In this situation, would it be better to have a ButtonPressListener interface and have it as a parameter in Button's constructor, or should the Button be abstract with the abstract method pressed()?
The resulting initiation code for Button would be like the following:
new Button(x,y,new ButtonPressListener(){
#Override
protected void pressed(){
// code
}
});
or
new Button(x,y){
#Override
protected void pressed(){
// code
}
};
Also, in other similar situations, what should be considered when choosing between the two approaches?
Thanks.
I prefer the listener.
Resons:
The listener will give you more flexability, when using java8 lambdas.
You can write one class that listens to several buttons
You can write one class that listens to a button and inherits some other class
By the way: You should consider using a setter, rather then a parameter of the constructor. This will allow to create buttons without listeners - or define more than one listener. Also parameters are a little bit harder to read then setter, as parameters cannot have names in java.
If you are trying to learn from this project, you might as well do both at the same time and find out what works better for you. Wenn you found out, refactor and throw out the less liked option.
Make a default implementation of Button.pressed() that calls the function of your listener implementation if set. Supply two constructors, one that sets the listener and one that does not.
Of course that is not an option is others shall use this API.
I have an application that is a Maths Game for kids. Since I'm in college, I've usually only had a god object for all my past projects but for this applciation I've split my code into multiple classes:
MathsGame.java: main class which initialises components and constructs and controls the UI.
DiffScreen.java: contains methods for use on the difficulty selection screen.
GameScreen.java: contains methods for use on the game screen.
EndGameScreen.java: contains methods for use on the end game screen.
MigJPanel.java: extends JPanel and sets layout to MigLayout and adds a matte border.
Each screen that the 3 XScreen classes control is simply an instance of MigJPanel and screens are switched to using a CardPanel container JPanel.
I'm wondering how I can divide my code to each class so that they are properly abstracted but I'm not entirely sure how to approach this.
Should my 3 screen classes be extending from my MigJPanel so these then can be instantiated?
So instead of having my DiffScreen, GameScreen, and EndGameScreen classes solely containing methods related to each screen which are then called from MathsGame, each screen will control itself within its own class.
If yes to the previous question, should the UI components for each screen be made inside that screen's class?
At the moment, all components for each of the three screens are created in my MathsGame constructor. This makes the connection between a screen and the class which 'controls' (I use this word very lightly at the moment) it even further apart. So each screen is just an instance of MigJPanel whose components are constructed in MathsGame. The only relation the EndGameScreen class—for example—has to the End Game screen is that when the MathsGame causes the End Game Screen to be displayed, anything done there makes a method in EndGameScreen be called from MathsGame.
I hope I explained myself well. If not, leave a comment and I'll clarify. Any help would be greatly appreciated!
Yes
Yes.
Focus on self containment and maintain areas of responsibility. It is the responsibility of each UI screen to manage it's content, no one else, in fact, you should guard against allowing unrestricted modification to these components and provide access only through managed methods indirectly (setters and getters), which allow the modification of the properties you want to be changed, and not simply providing the component via a getter, this prevents problems with people removing components you don't want removed, for example.
You could also use interfaces to maintain common functionality if required, so if the MathsGame really only wants to deal with a certain amount of the information/functionality, you can use an interface that all the other screens use which will simplify the process, as the MathsGame only needs to know about the class that implement the interface and not EVERY thing else that might be going on...as a suggestion..
Also, where should I put the code for switching between screens?
From my perspective, it's the responsibility of the MathsGame game to determine when and to which screen should be shown. What I would normally do, is provide some kind of notification process that the current screen can ask the MathsGame to switch screens, maybe via a listener or other agreeded interface. This would mean that each screen would need reference to MathsGame.
Instead of passing it (MathsGame) directly, I'd create an interface that MathsGame would implement (say NavigationController), which defined the calls/contract that each sub screen could use (nextScreen/previousScreen) for example.
Take a look at Model-View-Controller for more ideas
The GWT documentation comes with a tutorial on how to utilize the MVP pattern here. In this example, there are two views, and each replace the other as per the user action.
In these rather simple views, it didn't hurt much to cram all widgets that view has in one single class (view) only. But for a complex view, one would like to create individual views for components (with a corresponding presenter for each such component view), then combine those views into the overall views (this combined view may or may not have a separate combined presenter, since all sub-views already have corresponding presenters). Somewhat similar to creating individual widgets in separate classes that extend Composite, calling initWidget on them, and using them like mainPanel.add(new subPanel()) in the main panel.
So is it possible to do such thing in MVP pattern in GWT?
No, if you do so the entire DOM load in a single shot,even though you put if else conditions inside .
When building large applications with GWT,Using MVP and code splitting is a must – otherwise,
the entire application (i.e. JavaScript bundle) is downloaded in one chunk on the initial
load of the application, which is a good recipe for frustrated users!
By using standard MVP you can
Isolate of User Interface from Business tier
Easily interchangeable Views (user interfaces)
Ability to test all code more effectively
I suppose you are expecting like below
public class MainPageView extends ViewImpl implements MainPagePresenter.MyView {
#UiField
public HTMLPanel mainMenuPanel;
#UiField
public HTMLPanel mainContentPanel;
#UiField
public HTMLPanel mainFooterPanel;
.
.
.
.
.etc
Yes instead of panels as shown above , you can also use classes which have some elements inside.
Update:
To mainMenuPanel you can add your class like mainMenuPanel.add(new MyheaderClass()).
Where MyheaderClass extends of Panel or Widget .So that the all elements in the Class add to the mainMenuPanel
Inside your MyheaderClass class you may add labels, buttons ...etc by using this.add(mybutton)..etc
I'm developing this application where you can put text and drawings in a page. My application is in MVC pattern, and I need all the model parts, text and shapes to be of the same notion. They all extend an abstract ReportElement clas, for example.
But the problem is I crate a JPanel for every shape in the page, but to handle text I need to use JTextArea or something. To render the elements the View directly gets the report elements list from the Model and draws one by one. How can I distinguish a text element without hurting the MVC pattern.
I mean, it's impossible, right? I don't know, any ideas?
I think you're looking for the "Factory Pattern"
You need to have a wrapper method that returns a JComponent based in your own ReportElement conditions.
I would handle this situation by building a factory method that produces the right type of Swing component for any given ReportElement, like this:
public static JComponent buildViewForReportElement(ReportElement element)
Inside this method, you will need to actually inspect the ReportElement objects to see what type of component to build. This inspection might mean checking a field or a flag on each object, or might even mean using instanceof to distinguish different subclasses of ReportElement from one another.
Note that inspecting ReportElement objects like this violates the philosophy of object-oriented programming. A simple "object-oriented" solution would require all of your ReportElement objects to have a buildView() or getView() method, and so your GUI code could just call getView() on every ReportElement without knowing which implementation of getView() was actually being called.
Unfortunately, the object-oriented solution forces you to mix your view code with your model code, and it's good that you are trying to keep the two separate. That's why I would advocate keeping the GUI-building code out of ReportElement objects and instead using a factory method to build the right view for any given ReportElement.