I have some projects:
WebShared (Java Library project)
WebExternal (GWT Web Application)
WebInternal (GWT Web Application)
I have UI Binder's which are shared between WebExternal and WebInternal, and I organize those under the "WebShared" project.
I am now adding i18n support, and I want to use UI Binder's <ui:msg> tags, and consolidate them using the GWT-P mergelocales.py script.
Mergelocales.py works by running against a GWT app that was GWT compiled using the -extra parameter. Since WebShared is not a GWT app, running the script against it produces no output. Additionally, running mergelocales.py against WebExternal or WebInternal does not produce a file that includes the messages from the WebShared project.
I believe it would work if I converted the WebShared project into a GWT project, but then I would still have two separate properties files to send to the translation service, and I don't want to deal with combining files or managing multiple files.
What is the best way to handle this scenario using the available tools, OR do I need to create my own script?
Thanks in advance for the help.
Solved.
This actually works by default. When the GWT Compiler runs, it generates .property files for the UI Binders that are localized, even if used from a dependent project, and the mergelocales.py script runs against those property files.
Related
I am new to ExtJs.
When practicing in eclipse do we need to include the entire library(52 MB approx) in the appropriate location?
Is there any shorter version of this library?
Can I delete some files in the library which are not important?
What are the necessary .js files to be included for building a sample MVC pattern, CRUD operation support application in ExtJs 4.2?
For my setup, I include the /ext directory in my project, however I exclude it from the build path so that it doesn't slow Eclipse down. See Eclipse: Javascript validation disabled. but still generating errors?
Then, if you don't even want to see the directory in your workspace, you can create a working set.
I wouldn't recommend deleting/excluding ExtJS source files from your project, especially if you are using Sencha Cmd and/or using dynamic loading in your application.
If you really want to include the bare-minimum, you could get away with using ext-all.js, ext-all.css, and making sure you have all of the ExtJS image files.
I am developing an Eclipse RCP application, which contains 600~ strings, translated to a couple of languages by myself.
The point is that I have to deliver it to the translation team to translate it to several languages in a couple of months, and I haven't found any translation tool for eclipse, which would help the translation team in its job. Is there any application which analyzes the file structure loading the messages.properties and bundles.properties files, and providing a UI to translate it safely.
If not, which would be the best way to perform this task?
Thanks.
Assuming you have used the NLS tools in Eclipse, you should already have the properties files containing the translated strings.
Eclipse projects are translated through an instance of the Babel server.
This is in itself an Eclipse hosted project.
The Babel server environment is a typical LAMP environment. You could try setting it up for your translators by following the instructions.
If this seems to be a lot of work for only 600 strings, it's because it is.
It is easier to use a hosted service like Amanuens or Transifex to cooperate with your translators.
Globalyzer (http://lingoport.com/globalyzer) can run as an eclipse plugin (or as a stand-alone workbench) and supports extensive internationalization activities across teams of developers and a wide variety of programming languages.
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...
Context
big project with multi maven module or single maven module structure
Question
did you finally use multi-maven-module or single-maven-module structure?
Details
If you've worked on a big project that had long development duration and contains lots of functionality(i.e. not a trivial project), did you choose to split the project into multiple maven modules or went with the single-module approach?
For example, having a multi-module structure, crashes when running maven commands like mvn gwt:eclipse(see http://bit.ly/gs4Rmo). I guess this would have worked well with single module GWT project. And there could be other commands like the above that has issues with multi-module structure.
However, the multi-module structure could bring the benefits of a faster development, i.e. if you separate the "server" from "client" module, you could compile the business logic(server) separately and package it into resulting web archive. Compiling the GWT code, takes about 20 seconds, so if you only modify the server package, it could save you lots of time in the long run.
Which other cases like the one above did you encounter when working with a multi-module/single module project?
Thank you!
A few notes:
On development server you don't have to compile the code "by hand": dev server compiles the code automatically and reloads it. Just keep dev server running, change some code and then reload the page in browser. (this is only true if you change existing classes and don't change project structure)
Multiple maven modules have nothing to do with multiple GWT modules.
You would want to have multiple GWT modules (= multiple entry points) if you have code that executes in different environments: for example you have web and mobile sites that have quite different code bases. Then you would split the project into three modules: web, mobile and common. Then you'd reference common in both web and mobile.
Another case for multiple GWT modules would be if you, for some reason, want to have a multiple host (entry) HTML pages. There are rare cases when you'd want this, for example when you need to do redirects when integrating OpenID. The other case would be that you already have existing Web pages where you are only adding GWT to add some functionality.
Don't split the GWT project into multiple modules just to reduce download size: use Code Splitting instead.
If your main gripe is long gwt compile times then read: How do I speed up the gwt compiler?
We started with multiple modules and eventually merged into a single module. The main reason for this was maintenance of modules is a huge overhead. Each module had a pom to build the UI, RPC layer and backend services. So with 30 modules we had 90 maven projects to manage.
Merging the modules turned 90 maven projects into 3 with one parent level pom.
This considerably lowers maintenance overhead and improves build times. GWT's compiler is notoriously slow so having a single compile parsing source files once instead of multiple times makes things much faster.
On the flip side, a single module means the compiler slurps everything up into memory at once. This could make split points intolerably slow to find if you insert any in your code. Therefore if you intend to split, it may be worth considering where you're putting those points and arrange your project accordingly.
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.