How do I put a presenter widget behind a split point with gWTP?
Putting top level presenters behind splitpoints is straightforward as GWTP supports this out of the box but I'm not sure how to do it widget presenters... i.e. ones that are injected and don't have a proxy/place.
I'm using GWTP 1.0.
I've read this - it's all I could find on the subject - not so obvious and I think a little out of date (not for GWTP 1.0).
Have a look at this post https://github.com/ArcBees/GWTP/issues/333. You need to manually setup an AsyncProvider with Gin.
As well as this post should help.
Related
We've been using the recommended GWT approach of building parts of our application in an MVP manner. The logic we use is based on Google's examples - the Presenter fetches/prepares data and sets it on the View, and the View contains a reference to the Presenter which it calls (e.g. in UiHandlers).
Some parts of the application which we built should be reused in other views. For example - a view which is sometimes the "main view" of a part of the application - can be used inside a pop-up in another part of the application (of course, the views/presenters are initialized differently in this other case, but basically it is the same thing).
What would be the correct approach to do stuff like this? I cannot seem to find a suitable one without resorting to ugly hacky stuff.
For example - if I put the presenter of the reused component inside the main view - it is easy to initialize the reused component, but it is ugly to receive a result back in the main presenter. This can be solved by passing a runnable or creating a custom handler or passing the parent presenter itself to the reused presenter.
All of these approaches don't seem right to me though and seem ugly.
Any ideas/experiences?
What you're describing is a view being able to be controlled by 2 distinct presenters. Abstracting those presenters behind a common API, in the form of an interface, should be enough.
You can also see it as a composite widget being used within two distinct views. The composite widget would then expose events and a public API that both views could wire to their specific presenters.
See Activites and Places,It can help you to desing and structure you app.
https://developers.google.com/web-toolkit/doc/latest/DevGuideMvpActivitiesAndPlaces
.
I just want to know if this is the proper way to go about splitting up widgets in GWT that get too large, or if I am missing the concept of widgets/proper GWT usage all together.
I started out with a single class (widget), PCBuilder. As PCBuilder became too large, I decided to branch off and make two classes SuggestionPanel, and BuildControlPanel, both of which just split off PCBuilder's code into separate classes that still have access to the methods in PCBuilder:
This way, in my PCBuilder class, I can do something like this to add the SuggestionPanel and the BuildControlPanel to the tabs (TabLayoutPanel) that are specified in the UiBinder of PCBuilder while allowing for SuggestionPanel and BuildControlPanel to have their own separate UiBinder specifications:
My question is: Is this proper? Part of me thinks "no" just because it's not a nice way of doing it. On the other hand it works just fine, and my web application is somewhat broken up into manageable "sections" which is what I wanted.
Thanks for any insight.
It's fine apart from the fact that you have circular dependencies between classes.
Why do SuggestionPanel and BuildControlPanel need to call PCBuilder? Is there any business logic in it? RPC maybe? Separate that into another class.
First, you might want to take a look at GIN - this handles dependency injection. This is good for testability.
Second, if your app goes beyond one "page", then take a look at GWT MVP.
You should not consider your PCBuilder as a widget. Quoting gwt -
You construct user interfaces in GWT applications using widgets that are contained within panels. Widgets allow you to interact with the user. Panels control the placement of user interface elements on the page.
Coming back to your question, my take is to create widgets only if I can reuse the same element more than once. The rest of my layout logic goes into the view. Layout shouldn't be a part of the definition of the widget as much as possible.To conclude, push styling in css, push layout in the views; widgetize only if re-usable (and core) or if adding additional functionality to existing widgets.
This question already has an answer here:
GWT 2.1 Places example without Activities
(1 answer)
Closed 3 years ago.
On an existing project we’re using MVP (hand crafted) reasonably well. It’s understood and does mostly what we need. For a new project I'm looking at using the MVP framework built into GWT 2.1 (Activities and Places).
Our applications are mostly tabbed displays with each tab bound to a single view widget.
I’ve tried to use Activities and Places without success for this type of display. Part of the problem is that the example Hello World article ended up leaving me chasing my tail, too many new concepts for my brain to digest.
The Hello World sample IMO is not a sufficient introduction and doesn’t deal with many of the real world use cases. I was hoping someone could point me in the direction of any sample applications that use MVP for tabbed displays. Thomas Broyer has some excellent posts on his blog but these have still left me a little perplexed.
Previously I’ve used an AppController to handle tabs changes and single presenters for each tab. The new architecture in GWT 2.1 leaves me more confused that it should.
I'm using the gwt Activities/Places framework for a tabbed display, and it works great, BUT: I decided to abandon the TabLayoutPanel widget we had been using and create my own navbar (that looks like tabs) and a content pane. The effect is the same - it looks identical - but the implementation is much cleaner.
I think the problem is in trying to mix Activities/Places, which has its own idea of navigation, with a TabPanel, which has another idea of navigation. At first I tried to throw them together, overriding tab button behavior to trigger a PlaceController, which in turn switched the tabs around, but... it was messy. With the independent navbar / content pane, the PlaceController could do everything just like it wanted to. You just have to manually switch the views, instead of letting a TabPanel do it for you.
I also faced this problem but managed to make it work using one activity per Tab and each activity using a presenter (or more) to display the components of the tab.
Regarding the solution found by Riley Lark, I, instead, opted by using a Decorator pattern and, so, keep the original TabbedPanel. How ? Each activity gets injected (GIN) a presenter that contains a decorator for the TabbedPanel.
So, for example:
Tab1Activity gets injected with Tab1Presenter, which, in turn, gets injected with Tab1Decorator which decorates the TabbedPanel with a Tab1ContentPanel (this panel contains all the widgets to be displayed on the Tab1 tab)
Tab2Activity gets injected with Tab2Presenter, which, in turn, gets injected with Tab2Decorator which decorates the same TabbedPanel with a Tab2ContentPanel (this panel contains all the widgets to be displayed on the Tab2 tab)
Seems complex but, after creating the first decorator, it really paid off and I was able to keep the TabbedPanel and take advantage of the URL history management implicit in the framework.
in a définition of a widget, what is a better practice, and why, use the widget himself or the type "higher", example, it's a better practice to do
1) Button myButton;
or
2) Hastext myButton; (and set a button later)
thanks for your answer.
It is usually a good idea to use "higher" types or interfaces. By doing this properly you can hide implementation details. The code that uses an object looks at it as the one of a higher type and it is not important what is actually hiding behind it. This is good because you can easily change an implementation of the object without breaking anything.
For example when defining a panel in an application you should use Panel class instead of its implementation e.g. HorizontalPanel or VerticalPanel.:
Panel myPanel;
Then you can create a proper implementation of it, e.g HorizontalPanel:
myPanel = new HorizontalPanel();
If you then later decide to change myPanel to be VerticalPanel you will not have to change anything in the code that uses myPanel. Everything will work just fine.
However you must remember that you will be only able to use methods available in Panel class. Additional methods defined in e.g. HorizontalPanel will not be accessible. And this is actually what you should remember when choosing the type of your widgets. Your widgets should be of types which provide methods which you want to use.
In your example using HasText instead of Button isn't probably a good idea because HasText has only methods for setting and getting a text and you probably also want to have access to addClickHandler method available in Button and a few more.
So to summarize it is good to use "higher types" but they should not be "too high" to be useful.
The answer to that lies in the Model-View-Presenter pattern, that was introduced in last years Google IO presentation by Ray Ryan. There's also an official tutorial/docs - part 1 and part 2. There are also a number of questions here on SO that cover that topic :)
And a quick answer to your question (that will make more sense once you get familiar with MVP): use interfaces in the Presenter and their implementations in the View :) That way your Presenter stays oblivious to the underlying implementation/Widget you actually used (was it a Button? Or a Label? It doesn't matter, they both implement HasText).
I have posted this question on the Ext-GWT forums, I am just hoping that someone here might have an answer for me!
I am struggling to do something I initially thought was simple but am beginning to believe is impossible...
I have got a "layout template" of sorts - simply consisting of a few GWT DockLayoutPanel's within each other and finally ending in LayoutPanels. GWT's LayoutPanel is designed to size the widget (or Composite) that's added to it to its full size and does so perfectly with pure GWT widgets.
The idea of my "layout template" is that I don't know the EXACT height and width of the very inner LayoutPanel's because I may set certain panels sizes (of the outer DockLayoutPanels) differently when instantiating this template. All I would like is to add a Grid component to one of the inner most LayoutPanels and have it size itself (height AND width) to fit as normal GWT widgets do (works perfectly with a GWT Label for instance).
I am VERY new to GXT (as in I started using it earlier today) and I do realize that GXT builds its Components differently to the way GWT builds its Widgets on the DOM.
Is there anyway to achieve the desired result? I have tried adding the grid to a ContentPanel with a Layout of FitLayout, I have tried AnchorLayout, I have tried adding the grid directly... Nothing seems to work... Any advice or even a push in the right direction would be greatly appreciated!
Thanks in advance!
Xandel
Just a note on this post and the direction I have taken. When I started my GWT project and I was learning the basics and reading through others posts and concerns and advice, the one bit of advice I overlooked initially was quite simple - when using the GWT framework use pure 100% GWT components only.
I initially ignored these fair warnings of fellow developers because in the age of open source tools, and open source projects, one develops the mind set of "Instead of building a tool which will give me certain functionality, let me rather see if someone else has done it already". This mindset speeds up development and almost standardizes projects and methods of implementation.
However, I have found over the last two months, that when working with GWT it is best to not follow this principle. Maybe because its not as widely spread as other frameworks, or demands a very certain type of coding style but non the less my search for a (simple, sortable, JSON loadable) grid component and (validating, neatly styled) form component has been nothing short of a nightmare.
This isn't because they don't exist. They do. I tried ext-gwt, gwt-ext, gwt-mosaic, and gwt-incubator. It is because many of the components break away from the very simple layout foundation that GWT provides (in other words, the panels that you place the widgets on mostly need to be the panels provided with the tools). This in turn makes mixing components and getting the desired result near impossible. Which in turn breaks away from the let-me-find-a-useful-component mindset.
Just an interesting and final point which I think might be worth mentioning. So due to my realisation of the above mentioned point, I set about to write my own grid and form components. Which I have completed and are working fine for me (obviously, because I wrote them , I don't suspect they will be useful to everybody else). But in the process of writing the grid component, and needing the columns to size and space themselves out automatically once drawn in their parent panel, I found that knowledge of the panels final width is not known until finally being drawn (this happens long after all your code executes). So ironically I set about building a set of panels that communicate to each other, from the parent panel (who ultimately NEEDS to have knowledge of its size) right down to the most inner panels so that when my grid component finally gets drawn, I can fire a method called onSizeKnown(int width, int height) and do whatever sizing is required.
After I completed this I could do nothing but laugh. Because it suddenly became clear to me why all the other GWT components out there require their own panels. I in essence had to do the same to get what I needed working.
So in short, if you are a newbie GWT developer like I was and are (is?) looking for cool stuff to make your project look awesome - this is my advice - if you are going to use an external framework such as some of the above mentioned - use ONLY that framework. Do not mix its components with other frameworks. Learn to love that framework, and build your project from the bottom up using their panels and design methods. If this scares you and makes you feel nervous and limited then do what I did and write your own using pure vanilla GWT components. You will save yourself A LOT of time in the long run by following this advice.
Xandel
This solution is for GXT 2.2.0 and GWT 2.0.4 *
While the original poster has since moved on I recently ran into this issue and thought I would post my solution in case anyone else stumbles on this.
There is no reason you can't add a GXT Grid directly to a GWT LayoutPanel. The problem is that the styling/positioning approach of the two libraries conflicts. Basically it boils down to the fact that the Grid is sized based on its parent's height attribute, which is not set meaning that the grid's body get assigned a height of 0 and the grid itself gets a height equal to that of the grid header (if present).
So the solution is to undo what GXT does once flow has passed back to GWT. Here is a template solution:
class MyGridWrapper extends Composite {
private LayoutPanel widget;
private Grid<?> grid;
public MyGridWrapper(Grid<? extends ModelData> grid) {
this.grid = grid;
widget = new LayoutPanel();
initWidget(widget);
widget.add(grid);
// Set the grid's vertical and horizontal constraints
// ... populate the rest of the panel
}
#Override
protected void onLoad() {
// onLoad is called after GXT is finished so we can do what we need to
// Redo what the LayoutPanel did originally
grid.el().setStyleAttribute("position", "absolute");
grid.el().setStyleAttribute("top", "0");
grid.el().setStyleAttribute("bottom", "0");
grid.el().setStyleAttribute("left", "0");
grid.el().setStyleAttribute("right", "0");
// Undo any height settings on the .x-grid3 element
El mainWrap = grid.el().firstChild();
assert mainWrap.hasStyleName("x-grid3") : "Wrong Element: " + mainWrap.getStyleName();
mainWrap.setStyleAttribute("height", "auto");
// Undo any height settings on the .x-grid3-scroller element
El scroller = grid.el().firstChild().firstChild().getChild(1); // FUN!
assert scroller.hasStyleName("x-grid3-scroller") : "Wrong Element: " + scroller.getStyleName();
scroller.setStyleAttribute("height", "auto");
}
}
The assertions are there to help protect against what is obviously very fragile code so beware that this is a GIANT, GIANT hack.
--
Just in case you're wondering where the GXT Grid's structure is defined, you can find it in a template file in the GXT JAR under com/extjs/gxt/ui/client/widget/grid/GridTemplates#master.html
Have a look at com.extjs.gxt.ui.client.widget.grid.GridView#renderUI() to get an idea of how the grid is built.