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.
Related
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.
I'm a newcomer to JSF and am still trying to follow examples to learn the basics of how it works, and that has now lead me to begin exploring ICEFaces.
I love the concept behind GWT that you can just write in pure Java and have it compile down to JS and HTML, but I have also heard that ICEFaces offers a lot of things that GWT doesn't.
That led me to start thinking: is there a way to combine the two in a project, and get the best of both worlds? Is it possible to get the AJAX-centricity, rich UIs and underlying capabilities of JSF, but then use GWT to handle all the client-side code generation?
I looked at something called ICEPush which may very well do just this, but without fully understanding the roles both technologies play in MVC web apps I wanted to take a moment and see what the SO community thought of such a hybrid solution.
Having said that, I was wondering if someone could break down - in quasi laymans terms - the intentional difference between these two frameworks, and to give argumentation as to why they can be - or shouldn't be - combined inside the same project.
Essentially I'm looking for an AJAX-friendly, rich UI Java webapp framework that is open source, has an active dev community, and comes loaded decent/good documentation.
Also, not that beggars can be choosers, but I'd appreciate it if answerers don't solicit other solutions besides ICEFaces or GWT. I'm very well aware that these are not the only two webapp frameworks out there, and this question isn't going to convince me to start using either of them; I'm simply interested if their strengths can be combined, or not.
Thanks in advance.
JSF in general makes heavy usage of javascript. JSF or bette the JSF frameworks provide lots of components. The Javascript is generated on the fly.
GWT compiles the Javascript upfront. It provides some components as well. GWT is doing AJAX calls to its interfaces.
I'm not aware of any bridge that allows you to integrate JSF with GWT. So there is no interface and those technologies don't work together.
Both come with good documentation and have an active community.
ICEpush can be used directly with GWT; you can find out more about the integration here:
http://www.icepush.org/product/icepush-GWT.html
ICEpush provides a simple API to "push" notifications to the browser. Essentially, users (or browser windows) are organized into groups. When something interesting happens (such as a new photo uploaded to a photo sharing application) you can invoke a push on the group users.
In the case of the ICEpush GWT integration, you receive a callback into your "Java" code and can respond to the notification (such as, display the new photo). A GWT application can potentially run offline, but that does introduce the risk of application code being subject to offline attack.
In the case of ICEfaces, the ICEpush integration is abstracted away: rather than a "push" to a group, you "render" a group. With ICEfaces you request that all relevant pages be rendered on the server and any necessary page updates are sent to the browser. This makes it particularly easy to add Ajax Push features to an ICEfaces application.
So, the choice is really whether you want to use JSF or GWT. With JSF you have a standard server-side framework that emphasizes pages built from declarative markup. It is the natural successor to JSP application development. With GWT you have a procedural client/server distributed framework that emphasizes events and pages that are built from "Java" objects. It is the natural successor to AWT/Swing on the web. Both are very popular, so it's more a question of the technique you prefer.
I'm working on a client-side Java application for which I want to create a web-based user interface (which will be served up to a browser from the local app). At the risk of oversimplifying, its a microblogging tool that will support functionality similar to Twitter and Facebook. Its open source, and you can read more on our wiki.
Its important that this app is extremely easy to use, and I also want it to look good relative to contemporary web applications (such as the examples available on the Chrome web store). Since I am not a web designer, I'm hoping to use tools that give me an attractive UI "out of the box". Oh, and I need to keep the distributable file reasonably small (un him so whatever I use needs to be reasonably lightweight.
So far, I've looked at Sproutcore and GWT.
Sproutcore apps definite have the appearance I'm hoping for, but I'm not that familiar with JavaScript, and after some experimentation is not entirely clear to me how I will achieve some of the more sophisticated functionality that I think I'm going to need.
Being Java, GWT is more within my comfort zone, however I had a hell of a time just getting my development environment set up properly. It seems that GWT wants to dictate the structure of my application, but since the user interface is only a small part of it I'm not willing to build the entire app around GWT.
Something else I've been thinking about is using CoffeeScript (which seems more palatable him and him him him him him than JavaScript, and there are Maven builders for it), perhaps together with JQuery-UI.
What other options should I consider?
To recommend two big javascript frameworks Sencha and Cappuccino.
These have an extensive UI toolkit out of the box. The latter has an MVC framework build in, the former has a general JavaScript library build in. Both come highly recommended.
Also as recommended jQuery UI is a reasonable toolkit. I would personally couple Sencha for its rich UI toolkit and a lightweight MVC framework like Backbone. I'm afraid this does require learning JavaScript well.
You can also instead drive your JavaScript UI toolkit mainly from the server and skip the clientside MVC. For that sencha should surfice as a UI toolkit, but if you want meaningful functionality you will need some more structure. I would also recommend RequireJS for modular file management.
Take a look on Vaadin its based on GWT but simpler to use. I use it since 2 years and i'am not a designer too.
Take a look at jQuery & jQuery UI (jQuery Modile if you are looking to deploy to hand held devices)
Also, since you mentioned that you are not a designer, you might want to implement the front end in an MVVM pattern to separate the UI from the business logic of your applications. Knockout is a nice way to do with with decelerative data binding
I don't like writing plain JavaScript, so I'll tell you little bit about Java based frameworks. Recently, I've picked Google Web Toolkit.
Pros:
plenty of materials
Eclipse + Google plugin
Very intuitive API
3rd party libraries
Fancy widgets + optimized JavaScript
lot of generics
very active community
awesome async callbacks
Cons:
very slow debugging, that will drive you mad sooner or later
lot of deprecated code for so young framework
Mixed feelings:
You don't have to write declarative UI (you can do Swing-like development), but your code grows bigger and less maintainable, so it is quite probable that you'll eventually learn some declarative UI like UI Binder
Visual designer for GWT is somehow nice, but very unstable (eclipse) :(
Some considerations:
Do some prototyping with Vaadin. Try some debugging. Then try GWT and debugging on similar sized project. Consider debugging as the VERY important decision factor, because GWT debugging was the most frustrating thing for me.
Consider JSF + some nice rich component framework for JSF like RichFaces, IceFaces, PrimeFaces etc (but you app won't be "light" and "small" anymore if you really care). Be sure to be perfectly comfortable with environment (IDE + plugins), nothing beats JSF there (I'd pick RichFaces + Seam today, if full Java EE is option).
If you don't want to learn javascript I recommend you GWT with Sencha-GWT (GXT), you can develop all your app in java language, and also debug your code in java.
It is very easy to create a web app with this technology, and provides almost all funcionality available in javascript version.
Also you can mix it with hibernate and giled to persist your data, and giled helps you to serialize hibernate objects.
I have been writing an application in SproutCore for the front-end and a Java backend. In my mind this works perfectly.
The backend can stop worrying about HTML and JavaScript contents on the client side, if the request is XHR or plain request/response. I can implement the backends using plain old Java Servlets, and only worry about the data that is passed between the client and the server (JSON for the most part).
The client becomed fast and responsive, and SproutCore has a rich amount of components that you can mix and match.
So in other words with SproutCore (and Cappuccino and other full-blows MVC JavaScript frameworks) you can let your client do what it does best : Render and display HTML, CSS and JavaScript, while leaving your server to worry about what it does best: retrieve, store and update data. If you are interested, the source code for this project is available with the GPLv3 licence: https://github.com/joachimhs/EurekaJ
I have written an article about the differnt approaches between server-side MVC and client-side MVC here: http://haagen.name/2011/05/24/The_RIA_MVC_Model.html.
Also SproutCore comes with the MIT licence, so its avaiable for use without (m)any restrictions.
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.
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).