Developing traditional style webapps with GWT - java

In many JVM web frameworks survies and Indeed.com trends graphs, GWT looks to be the most (or among the top) popular JVM framework.
But AFAIK, GWT excels when the application is one page app -to some degree of course- (like GMail, Google Reader ..)
Does this mean that new developed Java webapps are one page apps mainly (not traditional request-new page response)?
Is it possible to develop SpringMVC or Struts2 style webapps with GWT? or it is not recommended?

Absolutely, it is definitely possible to build struts apps with GWT; at some level all the GWT is, is a convenient way of writing javascript (in my perl days, we called it 'syntactic sugar').
You can still use GWT-RPC, JSON, or HTML forms to communicate with the server.
You can attach to any arbitrary HTML element using RootPanel.get("id"); to add javascript widgets.
Almost every javascripty component on my employer's website is written in GWT: http://www.cohomefinder.com/ . The backend is an old fork of struts.
And here's a nice, though a bit dated, article about building 'normal' websites in GWT: http://www.canoo.com/blog/2007/03/13/building-a-regular-website-with-the-google-web-toolkit/
I'm not sure, however, that this use of GWT is where it really shines. One downside is a lot of javascript parsing on every page load. Code splitting can help with that, some.

Related

How can I use HTML & CSS to create the user interface for my java app?

I have just read this article: http://docs.oracle.com/javafx/2/webview/jfxpub-webview.htm It shows how to build a java app using the javafx library and also how to use some classes such as WebEngine and WebView to display a web page in the app, basically turning it into a browser.
Here is some relevant info from the article:
The embedded browser component is based on WebKit, an open source web
browser engine. It supports Cascading Style Sheets (CSS), JavaScript,
Document Object Model (DOM), and HTML5.
The embedded browser enables you to perform the following tasks in
your JavaFX applications:
Render HTML content from local and remote URLs
Obtain Web history
Execute JavaScript commands
Perform upcalls from JavaScript to JavaFX
Manage web pop-up windows
Apply effects to the embedded browser
I would basically like to entirely dispense with Java or JavaFX GUI tools, except for those required to display HTML and CSS, as described in the article, and build the entire user interface for my app in HTML and CSS. I would like various HTML buttons to cause events to transpire in my java code.
Does this seem like a good idea? And since it does seem like a good idea to me, I'm also wondering why would anyone ever use any other method to build a GUI in java.
I'm creating an entire desktop application with a single WebView, it is available at github. Basically it's UI is a single HTML file which links a dozen of JS files. To call Java from JS I wrap my requests into json and call a Java facade bean. It is also possible to call JS from Java in same fashion. Though it is possible to call Java directly by invoking a method on a Java bean with parameters of any type, I did have a few application crashes after which I decided to make it completely safe and stay with json. This app uses AngularJS and Twitter Bootstrap to render pages.
I had created a ticket in Oracle's JIRA for better Java integration (JSR-223) inside a WebView and their answer was it could be scheduled for Java 9.
The development is pretty fast, when the process is set up - it's hard to debug the app in the beginning because there is no debugger. Some top-level JS exceptions are not being caught as well. At the moment I'm having no issues with WebView in JavaFX 8. JavaFX 7 is unusable for me because of the problem with fonts.
Answering your last question - I have no idea, but the situation is completely the opposite. For some reason Oracle puts resources for JavaFX native components development, but not for better WebView integration.
You can use a MVC framework such as Struts2 or Spring MVC together with AJAX and build a user interface (the view component) completely with HTML/CSS. Sometimes, using a template engine such as FreeMarker3 also helps replacing default java rendering with pure HTML/CSS solutions.
Vaadin
Vaadin is a sophisticated servlet-based framework that creates server-side based apps that run your pure Java code while automatically rendering the user interface on the client side in HTML, CSS, and JavaScript.
You don't need to know about or do in programming in those web client technologies, Vaadin does all the web-related work for you. No web templates, no pages, none of that. Your Java code simply creates label, field, buttons, and layouts. Vaadin transforms those on-the-fly to be rendered in the browser. Pure Java on the server, no Java at all on the client/browser side.
Xojo
Vaadin is not "yet another web app framework". It really has no direct competitors in terms of architecture except the non-Java Xojo Web Edition which uses its own proprietary OOP language.
It looks a very good idea.
An alternative can be to use Jetty or a similar open source server but you have much more work to do for adapt it to your application.
An other alternative is to build a Java EE application but it is not so much agile for a simple web view of your app, Java EE gives you the possibility to build dynamic web pages using the Java Server Pages and manage the user requests using the Servlets but you have to submit to his structure and this is not useful for your easy application.

Making Web Forms: Java vs HTML

I am new in programming and this question may really be stupid but I still want to ask because I don't know what practices are possible and what are not. You see, right now I am studying basic J2EE. Our assignment is to make a web-based application using JSP and servlets. One of my problems is doing the forms.
I know that HTML is the best practice in making the forms in JSP because almost all people are using it(based on the examples on the books/internet). But Java also have its own forms which is the Swing, AWT and it all worked by using the events. If i don't want to use HTML, can I use Java's Swing/AWT or is it for the desktop applications only? Aside from what I've mentioned, what else can I use?
What you are talking about is called Rich Internet Applications RIA. These are web applications that make your web pages look like desktop applications. You can achieve this with Grails and Flex, GWT and JavaFX. There is a number of very interesting and great environments you can use like Vaadin, Open Laszlo, based on GWT. GWT and the frameworks based on it generate JavaScript and produce separate output for every browser environment.
These are the tools for the future. I do not really understand why these technologies are not mainstream yet.
Here is a list of the various RIAs frameworks available. Expect to welcome newcomers in SourceForge in the near future.
But Java also have its own forms which
is the JSwing, Swing, AWT and it all
worked by using the events.
Yes java has many Components in Swing and AWT.
And both Swing and AWT Components support Event Handling.
But I never have heard of JSwing.
If I don't want to use HTML, can I use
Java's JSwing/Swing/AWT or is it for
the desktop applications only?
Swing and AWT are for the desktop application only.
But as Orbit said
In Appletz? – Orbit
You can definetly use Swing components on an applet and then embed the applet on your JSP page.
I know that HTML is the best practice
in making the forms in JSP
Using HTML will be a lot easier than using Applet to make a form
As Andrew said
Applets are a PITA to develop and
deploy, and most users prefer pure
HTML (or dynamic HTML, using
JavaScript) to applets.
You can try out Wicket - seems like transfer your desktop expirence to web
Perhaps you need to think about what is running where, and how those programs communicate. When you develop a web application, you are co-ordinating a conversation between (at least) two separate machines.
On one side, you are running a web server, that serves up static content (simple files that are just sent out with no changes) and dynamic content (essentially files that are constructed only when needed, and that will change according to their situation - for instance a welcome page that displays the user's name). Plain HTML is static content, JSP and servlets provide dynamic content.
On the other side, you are running a browser. The browser can display static content, run javascript programs built into those pages, and embed specific types of applications. Examples of embedded applications are Flash and Applets.
So you can be clear, JSP and Servlets are NOT running on the client machine, they just deliver different content for the browser to display. A J2EE program is not delivered to the client, it just sits on the server carrying out one side of the conversation with the browser carrying out the other side.
A web form is just a lump of HTML that tells the browser to display text fields, buttons and other controls. The browser knows all about these things, and you don't need to write a program to tell it what to do to display a form and send the content back to the server. A simple form doesn't need to be dynamic - you're asking the same questions every time - so you can write it in pure html.
When the user submits the form, the data is transmitted to the server and you will need to write a program to receive that data and do something with it. That is the role of the servlet, which can receive data and respond - with another web page, probably using JSP to display dynamic content (ie. the answer to the form submission).
If that all sounds complicated, it certainly can be. There are various frameworks (Wicket, Struts and so on) that try to make it easier to develop web applications by hiding some of the details of the conversation, and carrying out common tasks automatically. However, the underlying mechanism is still the same - content from the server is displayed on the browser, which can send back messages such as form contents, or requests for different pages. Understanding the basic mechanism allows you to make informed choices about how you can do more powerful things.
Embedded applications allow you to run more complex software on the client - so you can display animations or custom controls. However, the software is ONLY running on the client, and still needs to communicate data back to the server. The server still needs to be running it's own software to receive that data and do something with it. As such, embedded applications don't make your job any easier, but do allow you more control over how things work on the client. However, a modern web browser gives you a lot of control over how forms are displayed and handled, so you need a good reason to ditch that and use something like Flash or an applet.
For websites, always use HTML (and Javascript, for things like input corrections, alerts and such). The less you use Java and Flash, the better.
Keep in mind that websites must be fast and efficient, users don't want to wait minutes until the Java applet loads.
I would recommend you to do in HTML. Because HTML can do wonnders and you can split your web apps sematically using HTML. And i recommend you to use Wicket(its an framework), where all are been splited. That is, web designing can be done separately using HTML, presentation can be done via CSS and the event handling all can be done via JAVA. And wicket takes care of all these connections too. So have a look on Wicket. And hope it helps you.!

When to use GWT and when to not

I am wondering if there are specific cases where GWT is not suitable? For example would it be approriate to re-develop Stack Overflow using GWT?
I am developing an app which has a Java Restlet API and I was planning on using GWT (previously I would just have used bog-standard HTML/CSS with back-end PHP code calling an API). I am wondering if there are reasons why I shouldnt choose to do this?
My answer is not full but I believe the following bullets may be useful.
GWT should not be used for applications that mostly present textual information and some pictures, i.e. not very interactive. For these applications GWT does not bring you a lot of benefits.
GWT should not be used by teams that have strong web skill and relatively weak java skills.
Do not use GWT if you are required to support browsers that GWT does not support officially. For example MSIE 6.
have a look at this topic GWT for big projects?
GWT is best choice to manipulate complex actions in a single page. like Google wave, Google mail ... you can easily update (ajax) any part of the page.
Because of the GWT is java-to-javascript compiler, user should wait the loading of .js files and it causes many and many problems if your web app is big. The bigger your project, the bigger javascript files, the more user should wait the loading of .js files
IMHO If you have a static looking website like a blog, news portals, etc which each page has its own identity and represents an entity and is requested separately don't use GWT alone (you can still mix it with server-side generated pages like FB).
For most of other web apps especially if users sign in to use your app or your app is interactive and there is no technical problem use GWT (like Gmail design).
I would propose to avoid GWT at any cost. I have experience developing huge project with GWT and it is nightmare, because of long development circle. If you have application in angularjs/react/jquery, you update source code, click F5 and reload it. You can quickly debug clicking F12.
If you use GWT on huge project, you have to wait ~1 min for app to compile. And then there is no good way to debug it. Google provided special browser plugins, but they worked unstable and didn't support last versions of browsers, so I had to downgrade FF. Also huge GWT app debuggin takes tons of java memory, so you have to provide more memory to tomcat. And finally in practice you can't avoid learning js, you will have to learn it if you do modern web development.
UPDATE 15.05.2017: My answer was downvoted by GWT fans, but I'd like to note, that my info is up to date: 1-page hello world app rebuild cyrcle takes about 30seconds with last IDEA and 10Gb mem SSD notebook. I also asked friends having GWT in production for serious project: they claim 2min is average redeploy time.

Ajax and sophisticated graphics in Java web-app

In my opinion WWW will sooner or later come to full-blown AJAX web-sites, so that we wouldn't have
page reloads every time you click somewhere.
Now I want you to ask this.
What tools and frameworks can one use to make a Java Web-application running on Tomcat
have AJAX functionality like "in-place, with no page reloading" table sorting by
clicking on its column header, multi-tabs that enable opening at once the new screen to the user without reloading a page, saving data in the database without reloading a page, and other similar things that we do not usually see on web pages.
That's all should probably be based on AJAX.
But how to integrate this AJAX functionality with existing java web-frameworks, let's say Spring MVC?
Or maybe there are other frameworks that better suit such needs but that can be integrated with core Spring?
Your question is rather confusing--AJAX calls are all client-side, any server-side technology can return data to the client.
That being said, you may try taking a look at Google Web Toolkit.
With the GWT SDK, you write your AJAX front-end in the Java programming language which GWT then cross-compiles into optimized JavaScript that automatically works across all major browsers. During development, you can iterate quickly in the same "edit - refresh - view" cycle you're accustomed to with JavaScript, with the added benefit of being able to debug and step through your Java code line by line. When you're ready to deploy, the GWT compiler compiles your Java source code into optimized, standalone JavaScript files.
Among other things, GWT supports built-in serialization of objects for transfer to your Java servlets, allowing for crazy-easy (the technical term) integration of your GWT client and existing Java technologies.
Homebrewed/3rd-party Ajax stuff with JSF isn't that easy since you have to take its lifecycle and component tree into account. You would need to write your own ViewHandler. Rather look for what's already available. To start, JSF2 already provides builtin Ajax functionality with under each <f:ajax>. There are further also a lot of Ajaxical JSF component libraries, like RichFaces (showcase here).
No wording about Spring as I don't do it.

Google Web Toolkit -- only for Gmail type applications?

I am trying to build a web application, similar in feel to something like GMail, with one persistent AJAXy page.
I am told that GWT is the way to do this most effectively. However, I also want a framework that I can use for other things besides single AJAXy pages. Is GWT more scalable than this, or should I spend the time and build this thing in ASP.net MVC or Django?
I should mention, I'm trying to LEARN a framework that will be suitable for me to do whatever in.
You can use GWT also for parts of the page (a single widget or two), but yes, you are right,
even then it is geared towards the case where you do not refresh the page it lives on.
GWT works fine for both cases. I've written a couple applications at work with it, and I haven't had any trouble with multi-page navigation. As Thilo also mentioned, you can use as much or as little of GWT for manipulating your page(s) as you need or want.
You can do both styles of applications in ASP.NET MVC or GWT.
GWT makes it easier for GMail-type applications eg: web applications which mimic desktop application functionality.
On the other side, ASP.NET MVC is easier for dynamic sites. EG: This site is built on ASP.NET MVC, and if you look at it, its behaves more like a dynamic and interactive web site rather than a desktop-like application.
So its just easier to do web sites in one, and web applications in the other. So I'd think about what type of app you'd rather spend your time on and choose the framework accordingly - Realising, of course, that you can do both types of applications in either.
The nice thing of GWT is that in the end all you have is HTML and JavaScript. You can combine it with any other technology.
You can use GWT for the one page that needs ajaxy stuff and the rest with something more traditional.
Or you could even write everything with another framework and then put a GWT widget that needs more AJAX behaviours in a dedicated location of your page.
If you want to stay in the Java world you can use JSP,JSF, Struts, Wicket, or any other framework.
If you want you could even just combine GWT with a .NET or PHP. Just don't use the GWT RPC in that case (use JSON or some simple XML encoding instead).

Categories