I'm using GWT (2.0.x) to develop a large scale and modularized application, but some modules have a lot of classes.
I'm facing a problem with GWT in development, because the DevMode it's taking a long time (processing) when I change every client-side class and refreshing at the browser.
My last option is to split more that modules, but I'm thinking to edit the GWT-DEV source code and "tell him" to do hotdeploy only on selected classes.
I have another option rather than edit GWT-DEV source code ?
Try using GWT.runAsync() to lazy load your code. If you can load only those modules that you need. You can make fairly complex web apps using GWT which run very fast. Hope you are following the MVP architecture recommended by google. Any extra information regarding the number of your classes etc will be helpful if figuring out if you need to reconsider your architecture or not.
Related
I would like to write JUnit test for my Eclipse RCP while I continue developing the code. When starting the application the different plugins initialize variables of various plugins/classes (mostly within their start methods) which are needed for the correct functionality.
If this initialization doesn't happen, it is impossible to test code because it depends on those values.
How do I solve this issue without creating a lot of dummy values?
What is the general approach to testing Eclipse RCPs?
You're facing a common problem: Too many dependencies. You need to cut them.
With Eclipse 3, this is going to be somewhat hard. Try to split the code into things that depend on the Eclipse platform running and everything else. Eclipse often uses interfaces, so you can test many things using mocks.
With e4, things got more simple since many services will be injected, making mocking and testing even easier.
But the goal must always be to have as much code as possible that doesn't depend on SWT or the platform. Create your own interfaces if you have to. The runtime imlementations just wrap Eclipse code. For tests, you can use mocks to simulate the Eclipse runtime.
You can run tests using JUnit plugintest, that will start up the plugin framework and will allow for testing of plugins. But this usually only solves some of the issues. The best suggestion is as Aaron suggests to separate functionality as much as possible to the point where all your actual code are just plain old java objects that you can test normally. All dependencies to Eclipse are in different classes and are kept as thin as possible so that they dont require testing.
This can be difficult to achieve, so mocking may be required. Another trick I've resorted to at times is to use Java reflection to change values of private fields, see this question
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.
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.
is there any drag and drop environment to work with GWT widgets.
or any user friendly IDE or plugin on IDE's
i remember using some thing like MyEclips for developing Hibernate was better then working with .xml files.
The Eclipse-based WindowBuilder Pro supports GWT and is now free, courtesy of Google.
I tried GWT Designer, http://code.google.com/webtoolkit/tools/gwtdesigner/index.html, but I think for now I'll stick to code the guis myself by hand.
The main reasons are:
Sometimes, it takes a little while (longer than I can wait) to load the design mode.
Sometimes it breaks after you modify code underneath.
Sometimes, does not do what you expect it to do.
I would suggest you giving it a try and see if it works out for your needs.
In my opinion, the experience using it has been frustrating than encouraging.
In order to provide nice URLs between parts of our app we split everything up into several modules which are compiled independently. For example, there is a "manager" portion and an "editor" portion. The editor launches in a new window. By doing this we can link to the editor directly:
/com.example.EditorApp?id=1
The EditorApp module just gets the value for id and loads up the document.
The problem with this is ALL of the code which is common between the two modules is duplicated in the output. This includes any static content (graphics), stylesheets, etc.
And another problem is the compile time to generate JavaScript is nearly double because we have some complex code shared between both modules which has to be processed twice.
Has anyone dealt with this? I'm considering scrapping the separate modules and merging it all back into one compile target. The only drawback is the URLs between our "apps" become something like:
/com.example.MainApp?mode=editor&id=1
Every window loads the main module, checks the value of the mode parameter, and and calls the the appropriate module init code.
I have built a few very large applications in GWT, and I find it best to split things up into modules, and move the common code into it's own area, like you've done. The reason in our case was simple, we had some parts of our application that were very different to the rest, so it made sense from a compile size point of view. Our application compiled down to 300kb for the main section, and about 25-40kb for other sections. Had we just put them all in one the user would have been left with a 600kb download, which for us was not acceptable.
It also makes more sense from a design and re-usability point of view to seperate things out as much as possible, as we have since re-used a lot of modules that we built on this project.
Compile time is not something you should generally worry about, because you can actually make it faster if you have seperate modules. We use ant to build our project, and we set it to only compile the GWT that has changed, and during development to only build for one browser, typical compile times on our project are 20 seconds, and we have a lot of code. You can see and example of this here.
One other minor thing: I assume you know that you don't have to use the default GWT paths that it generates? So instead of com.MyPackage.Package you could just put it into a folder with a nice name like 'ui' or something. Once compiled GWT doesn't care where you put it, and is not sensitive to path changes, because it all runs from the same directory.
From my experience building GWT apps, there's a few things to consider when deciding on whether you want multiple modules (with or without entry points), or all in one: download time (Javascript bundle size), compile time, navigation/url, and maintainability/re-usability.
...per download time, code splitting pretty much obviates the need to break into different modules for performance reasons.
...per compile time, even big apps are pretty quick to compile, but it might help breaking things up for huge apps.
...per navigation/url, it can be a pain to navigate from one module to another (assuming different EntryPoints), since each module has it's own client-side state...and navigation isn't seamless across modules.
...per maintainability/re-usability, it can be helpful from an organization/structure perspective to split into separate modules (even if there's only one EntryPoint).
I wrote a blog post about using GWT Modules, in case it helps.
Ok. I really get the sense there really is no "right" answer because projects vary so much. It's very much dependent on the nature of the application.
Our main build is composed of a number of in-house modules and 3rd party modules. They are all managed in seperate projects. That makes sense since they are used in different places.
But having more than one module in a single project designed to operate as one complete application seems to have overcomplicated things. The original reason for the two modules was to keep the URL simple when opening different screens in a new window. Even though had multiple build targets they all use a very large common subset of code (including a custom XML/POJO marshalling library).
About size... for us, one module was 280KB and the other was just over 300KB.
I just got finished merging everything back into one single module. The new combined module is around 380KB. So it's actually a bit less to download since most everyone would use both screens.
Also remember there is perfect caching, so that 380KB should only ever downloaded once, unless the app is changed.