I'm learning to use GWT 2.0 and I'm trying to convert the StockWatcher demo to use the UiBinder. the demo uses stocksFlexTable.getRowFormatter().addStyleName(0, "watchListHeader"); to add styles, but when I add <ui:style> to my XML and move my CSS I can't seem to figure out how to make the style work because there is no stocksFlexTable.getRowFormatter().addStyle(). Does <ui:style> just not work with FlexTables?
I tried to deal with it as well with no success. I believe though that dynamic widgets such as FlexTable are not fully supported for obvious reasons - i.e. you can't preset the style for the nth row when you don't really know how many rows the table will hold. Also, providing some arbitrary way to do it for the first only, or odd rows etc. would require more expressive power than what the GWT developers seem keen to offer (they try to stick close to XHTML) and i believe they state at the wiki at somepoint that declarative syntax is by no means a templating language. Anyway, you can always experiment with #UiFactory and #UiField(provided=true) to try and stick close to GWT recommendations. But still, you ll have to set any such values programmatically.
I had success by removing the section completely and moving all of the css for the FlexTable into the application css file.
Related
I'm tired of all the superfluous crap GWT renders into my HTML. Is there a setting I can turn on/off to prevent GWT from adding its default css classes on elements?
I want to get rid of things like class="gwt-RadioButton" and class="gwt-InlineLabel" from the rendered HTML. I don't use their themes so all it does is add unnecessary bloat.
No, it's not possible.
IIRC, it was suggested a long time ago but no one took the time to do it. Particularly as it apparent doesn't have a big impact in performance (either output size or runtime perf)
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...");
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.
I wondering why swt is so inconvenient to use. We as programmers have to produce tons of unnecessary source code. Here an example.
Label label = new Label(parent, SWT.NONE);
label.setText("labelname");
The minimum would be like this:
createLabel(parent, "labelname");
I build up a convenients library and I would like to know if there is something similar or why SWT or JFace don't go this simple way. Is there any drawback in having some more constructors that cover 80% of the programming task.
Have a more detailed look what I have done.
SWT: More Convenients Please
I suggest trying Google Window Builder Pro. It is a plugin for Eclipse that allows for the graphical development of GUI's in SWT, Swing, RCP, JFace and others. GWB writes the code which specifies the GUI layout and all you must do is write code to handle events.
As far as I know there is no such generic library. The one instance which provides some basic factory support for swt control creation is JFace Form Widget. Also have a look at this org.eclipse.ui.forms.widgets.FormToolkit.
From your implementation it appears that you are assuming the GridLayout as the default layouting style. Apart from that a control may have many layout related data like, its indentation (horizontal and vertical), span etc. Which is not easy to cover with factory methods.
If you don't want to put in the extra effort of writing the code for layouting the widgets and all then have a look at the Visual editor at http://www.eclipse.org/archived/.
Also, eclipse itself is moving towards the the Model Driven Generation (http://www.eclipse.org/e4/). It won't be a wonder if we will see a Netbeans like UI designer for SWT (by the way i have written a version for our tool using eclipse modelling framework and GEF).
Still I would suggest you to write the mundane layouting code by hand because it will improve your SWT understanding.
Bytes are very cheap to produce, and I'd debate that SWT "is so inconvenient to use" - well if it's automatically producing it, how is that inconvenient ?
Our computers are so fast that we couldn't even perceive the difference... and time saved is huge.
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.