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)
Related
I've been working on a website and from time to time some elements are disappearing from the document. I've figured out that it's because in CSS document the early lines are not fully commented. I would like to ask why if even such a tiny thing like Skeleton's default version text is not fully commented or some of the classes or id's don't have a closing bracket then the whole website has layout problems. What skeleton's version has to do with page's body color ? This is really confusing.
Here is the HTML and CSS :
http://codepen.io/anon/pen/vIchA
I would be glad with any help. Yours truly,
D.
Browsers have to guess how to render bad code. Sometimes they will guess and render it correctly, other times it will look weird.
Different browsers are likely to render it differently (though error handling standards are improving)
In this case, your demo lacks a "/" at the start, which means it is trying to render the comments as css. The comments are not css, so it gets confused and does the best it can.
A quick way to find any bugs in the css is to use this:
http://jigsaw.w3.org/css-validator/
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 have a JFace TableViewer with an SWT Table, and I would like to custom render the content of some cells. I would like to use an SWT Control to render the cell content.
I would prefer to have only one instance of the Control doing the rendering, but if I have to instantiate one for each row, that would be acceptable.
Next, the solution MUST be compatible with the ContentProvider/LabelProvider approach (I am using EMF). This means that I cannot use the solution described in Sniplet 126 (http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.swt.snippets).
Next, I though about using custom drawing. But here the catch is, that I have to send individual drawing operations to the graphics context. I was trying to have the Control render the content for me by calling redraw() or print(GC) upon SWT.PaintItem, but that just lead to uncontrollable flickering.
At this point, my best guess is to use SWT.PaintItem to do the drawing. This will result in duplicate code, as I already have a Control that can render the content the way I'd like it. I'd like to prevent this redundancy.
Any help is appreciated!
Well, after banging my head against a wall several times I made some progress. Specifically, I found this formu entry:
http://www.eclipsezone.com/eclipse/forums/t115489.html
It actually offers two solutions: The first solution actually uses widgets (not recommended due to performance, but I knew that before). I will try this out, and may post here how it goes.
The second solution suggests using StyledCellLabelProvider. I looked into this before, but it isn't powerful enough for my purposes. At least that's what I think right now.
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.