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.
Related
I recently started working with mason and hit upon the feature_brick which has saved me a lot of time, but there's something I quite don't understand about this feature structure.
The brick creates a feature folder with three main widgets: FeaturePage and FeatureView in view/feature_page.dart, and FeatureBody in widgets/feature_body.dart. I understand that FeaturePage is responsible of providing blocs with a BlocProvider widget, and FeatureView is where the UI is and where BlocBuilders should be at. But what about FeatureBody?
To me it seems like FeatureBody is doing the job of FeatureView, leaving the latter class mostly useless. Am I missing something here?
As far as I know, this separation between page and view is mostly for testing purposes. Is the separation between view and body helping in any way to this?
Feature folder structure
feature_page.dart content
feature_body.dart content
I've been developing using GWT 2.3.0 and GXT 2.2.5. I was finally able to move up to GWT 2.4.0 and decided to look into what it would take to migrate to GXT 3.0, but right off the bat I hit a snag.
The application does a lot of blocking the user by masking the browser. I use the following commands to do so:
XDOM.getBodyEl.mask();
XDOM.getBodyEl.unmask();
First thing I noticed was that in 3.0, XDOM no longer has the getBodyEl() method, so I have no way of retrieving the top document widget from anywhere in the application. I do see there is now a Mask class, but since it requires an element parameter to work, I'm still in need of a reasonably easy way to get the document body element.
I've tried searching through the Sencha forums with no success. Any suggestions as to how I could do this?
This is one of those good news/bad news situations. The good news is that El is gone, no more confusion with when to wrap, when to El.fly, when to save a reference, etc. More good news: the new version is called XElement, and to turn an Element into an XElement, you simply cast (either java cast or jso .cast()):
Element elt = ...;
XElement oneWay = elt.cast();
XElement theOtherWay = (XElement) elt;
Either way works, no overhead. All the magic of El, with none of the confusion.
Except for the bad news. But first, some additional good news:
This change is part of a bigger strategy to try to do things The GWT Way, simplifying how many guides are needed to do anything, and getting rid of some of the duplication that GXT does of existing GWT features. Most of that duplication makes sense either when you look at how GWT has grown over the years, and the rest usually make sense when GXT needs a little more power than what GWT offers (layout panels vs layout containers, RootLayoutPanel vs Viewport, HasData vs Stores, etc). Other areas where GXT is now using GWT stuff: HTML, Label widgets, SafeHtml and other string formatting (except XTemplates, which is SafeHtmlTemplates plus awesome), supporting RPC/RequestFactory/anything-else-that-looks-like-an-object, the Cell API, the Editor framework, etc.
Bad news:
Now that it is Just That Easy to get an XElement out of anything, most of the convenience methods to transform things into El objects are gone too. XDOM is still there, but it only does a few things now, mostly things that DOM or Document can't do for whatever reason (side note: GWT's DOM class is at least half deprecated now and may be going away in GWT 3 or so).
So, when you get the dom element that you want to do something with (like mask), you have to cast it first. In the case of your body element masking, this will look a little like this in GXT 3:
Document.get().getBody().<XElement>cast().mask("Loading...");//or null if you don't want text
You could also grab the Mask class and do it that way (this time with a java cast to demonstrate that its all the same):
Mask.mask((XElement) Document.get().getBody(), "Loading...");
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
.
Is it possible to create a GWT form without manually specifying sizes of components ?
I'm looking for layout managers that work a bit like in Swing, where you can simply pack things in a panel with a proper layout manager and constraints and never care about size/width/height. However it seems like in GWT all typical layouts (eg. Dock, Horizontal/Vertical) either require size parameter or don't exist (GridBag, unless you count in very limited FlexTable).
Such layout exists in GXT, but I would recommend to use plain-old CSS + HTMLPanel. It will give you in the end the same result, but in a little bit different way.
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.