Has anyone been able to integrate the wonderful shorthanded syntax of LESS with the awesomely module, re-factor friendly and type-safe CSS of GWT UiBinder?
<ui:style with="com.lesscss.gwt">
.selector{
/* Can I haz LESS in here? */
}
</ui:style>
Naturally, you can use LESS with GWT -- You just have to use non-compiled css. I want my css to go through the LESS compiler, and then the GWT compiler.
There are no direct libraries for that, no.
LESS doesn't even have a java compiler, so I really don't think it's ever going to happen.
Suppose you could write a pre-compile routine that will go through your ui.xml files, compile contents of ui:style nodes and put the compiled versions back. Then you will run into continuous problems with your IDE complaining about improper CSS code.
As said before, there was no libraries to do that directly. But there is now ;) !
I recently wrote and published a library (HexaCss for GWT) which allows to bind a GWT application to external CSS files, while keeping type-safety and optimizations like pruning and css name obfuscation.
You use it like the traditionnal CssResource (so typesafely), but instead of binding to a CSS file Inside your GWT project, it binds to any external CSS file that you want (you can even bind multiple CSS files to the same application which gives you themes for your GWT application).
So in your case, the external CSS file would have been generated with HexaCss. That's what I do on many projects.
You can even use Sass, GSS and so on. You can also use the already written bindings for Bootstrap and Skeleton.
A sample which resembles to your question is this one, where the CSS is generated with Less, and used in GWT with HexaCss, which is then usable from UiBinder or Java directly.
Link to the sample : http://lteconsulting.fr/hexacss/demo/sample3/index.html - This is a very ugly demo showing only the idea. You can switch between themes with the listbox on the top.
Hope this helps !
Related
Question is about Google GWT Designer. GWT Designer can work with .java files without any .ui.xml files. But I have a gwt project where design is realized with .ui.xml files and java classes. It more complex then just java class. Do you heve any ideas what is it? May be it should be refactorized?
Thank you!
Firstly there's no need to refactor ready made UiBinder if it written well. This's a great GWT framework allowing separation of logic from view. If you reject it your project will be very difficult to maintain.
Secondly one and the same GWT project can contain the view implemented both in Java code and in UiBinder xml files. This situation occurs with a support of old projects where UiBinder wasn't yet. Uibinder is a much more modern approach which has many benefits. That is if you for some reason prefer declare view only in Java code without xml then write it in Java code. And this will coexist and work properly.
And most importantly present-day GWT Designer has support UiBinder. Otherwise, no one would use it.
We're building a large enterprise application (dozens of modules) with GWT and need to decide whether to use ClientBundle or not. I was curious what pros/cons the StackOverflow GWT community view as deal makers and deal breakers for such a use case.
As far as we see it currently:
Pros
All images/css files that take up server resources to download are eliminated
Client loads faster because of the above (i.e. inlined image urls)
CSS names are obfuscated, so namespace collisions are eliminated
CSS is automatically optimized / verified
Unused CSS classes are eliminated (above)
Java reference to class names are replaced with refactorable css interfaces
UiBinder reference to class names are replaced with refactorable css interfaces
No more big "main.css" fails as resources are module bundle specific
Cons
For maintenance CSS becomes either unreadable in obfuscated mode, or extremely verbose in debug mode
More steps needed for basic CSS work (like adding class)
All devs must know Java,CSS,HTML nuances
CSS3 and other at-rules (i.e. #font-face) are not supported by GWT natively
Increased compilation times
Thanks!
I have been using client bundle heavily in m-gwt.
One thing that was bothering me was styling for devices that did not have dev mode. So styling could mean recompiling the complete app.
Mostly all CSS3 Rules can be used in ClientBundle by using the literal function, so that should be okay. It gets a little tricker with #media queries. You can inject the css as a simple textresource as a workaround, but its kind of ugly.
When you are talking about several gwt modules, consider using multiple clientbundles so you can still use split points to keep the download file size under control (Depending on how big your .js files get)
I have used clientbundles in several big gwt apps and for me compile time checking and refactoring support beats the little quirks that are still in client bundles.
Just two additional notes:
There is a utility available in GWT which allows to automatically create the interfaces for your CSSResources
It's true that debugging styles can be a little bit cumbersome because of the obfuscated names. I had good success by using Firebug to change styles in dev-mode directly in the browser and when I am satisfied I change them in my GWT app.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...
Our webapp is implemented in GWT 2.2, with heavy use of UIBinder. I really like UIBinder's ability to define styles either inline with the HTML, or at least in a <ui:style> section. As a programmer, this modularity really appeals to me, as it puts the styling right where it's used.
And for styles that are used in more than one place, I refactor them to a CommonStyles.css/CommonStyles.java, and refer to that in my *.ui.xml files.
This has worked great so far, but now the company has contracted an HTML/CSS designer to re-work the design. We spent a few days trying to get him up to speed on Eclipse & GWT, without much success. To meet a deadline, we ended up having him just deliver an old-school giant CSS file to us, which we then painstakingly refactored back into the various ui.xml modules.
My question: Is it better to maintain a single, old-fashioned giant CSS file for a UIBinder app, so that designers can work with it? It pains me as a programmer to do things this way, but it seems like it's the only practical way to have non-programmers work on the design.
Is it unreasonable to expect designers to know an IDE such as Eclipse or Intellij?
From the perspective of the programmer of a company with one programmer and one designer:
The designer on my team never used eclipse or Java before our current project. We started using UiBinder stuff heavily about two months ago and, with maybe a couple of hours of help from me, he's managed to become quite proficient. He's now checking finished & laid out widgets into the source himself, with perfect CssResource etc modularization. I still set up the corresponding .css and .java files for him, but then I throw the setup at him, he writes 90% of the ui.xml & .css bit himself, and I come back and implement his ui in java afterwards. Occasionally I have to change a <div> to a <g:Panel> or whatever. He has not complained about it being too hard. Now he's starting to explore the extensions to css that gwt provides, like constants and expressions.
I'd say you shouldn't have to give up the benefits of UiBinder for the sake of your designers. In my own project, I expect to have to set up all of the code and generate templates for all of the Java interfaces, but I expect my partner to be able to add his own styles, separate css intelligently (e.g. CommonStyles.java vs. ThisWidgetStyles.java), and understand what's happening when his style names turn into GVDWK.
I am on searching special features of GWT which are present only in GWT and not in other web framework. I am a student and I am not well acquainted to the many web frameworks on the market, so if u can help me increasing my list of special GWT features, it would be a great help. Some which i know are:
1. GWT allows using java to program
web. (only, it also allows merging
javascript through JSNI of course)
2. The developer does not have to be a guru in browser incompatibilities
to develop web sites which works on
a variety of browsers because
incompatibilities are handled by GWT
through differed bindind
3. GWT allows easy integration of popular Java Tools such as ,
hibernate through gilead
4. GWT enables server implementation not only in java but also other
languages such as php
5. GWT enables code splitting which improves application interactivity
by allowing javaScript file to
download only when required
6. In essence GWT is toolkit, it does not force a way to program,
other layers can be placed on top of
it to program such as placing MVP or
MVC framework on top of GWT and then
develop app
7. GWT MVP is great because first it allows collaborative working, faster
testing with JUnit and the event bus
allows many updates in client side
application by placing event on the
event bus
8. GWT compiled java files to obfuscated mode which is first small
and make the application safer
because bots fails on the javascript
generated during the obfuscated mode
In case in the 8 points, i've mention something which not special to GWT, then let me know.
There's also 'perfect caching', which is the term used to describe the way that GWT optimises JavaScript for each browser.
Instead of building a large JavaScript file, with code that can handle all of the various browsers, GWT builds multiple JavaScript files at compile time, and downloads only the one that is relevant to the browser type that is being used.
EDIT: Every time you make a change to your Java code, GWT changes the name of the corresponding JavaScript file. Web servers can turn on caching for the JavaScript files (so that browsers won't re-download the same file), assured that the name will change when the Java code changes, and the browser will then download the latest version.
EDIT: I also really like the CssResource feature. By creating obfuscated CSS style names, GWT effectively gives each widget its own namespace for CSS styles; for example, I could define a 'pretty' style name on two different widgets, and have those styles using different CSS rules. Of course, it is possible to share CSS styles between widgets too.
Image resources are cool too. They optimise the way that images are downloaded and accessed.
Don't forget internationalization.
I think you pulled together a pretty decent list of differentiators there already. I think that one point worth adding is the RequestFactory feature in the most recent release, which, if you will, is simplistically speaking and RPC for data and makes it quite easy to develop Create, Read, Update and Delete - type (CRUD) of applications.
There are other, more important/wider accepted GUI-Frameworks that are based on Java.
There are for example Struts and JSF. That's why some of your points don't fit only for GWT, but for all GUI java frameworks in general, e.g. bullet point 1, 2 & 3.
But to add another one:
I think GWT is an easy way to code an AJAX-application, because it hides the AJAX stuff quite well. Wouldn't you agree?
Furthermore, GWT is a proprietary framework (which is somehow a unique property). JSF is standardized and Struts is lead by Apache.