I am in the process of beginning development of a web-based user interface and am looking for some expert advice on the right direction for my project.
Since our server-side is to be developed using Java, I am planning to use scriptless-JSP and an MVC framework called FrontMan. FrontMan is a lightweight Java-based MVC framework similar to Struts. I have played around with it and like it. The plan is to use scriptless-JSP assisted by JSTL and JSP tag files. I worked out some prototypes using these technologies and I liked what I had.
Now I am in the process of planning out the client-side stuff. My plan is to use JavaScript, jQuery, jQuery UI to build the front end. During my investigation I came across a very nifty JavaScript MVC framework named JavaScriptMVC. I have to say I really like it. It is not just a client-side MVC framework, but also includes tools for testing, documenting and deploying.
The more I engage in figuring out the client-side plan, I realize that I think this is going to be more of a JavaScript (client-side) app. I am leaning towards doing as much of the work in JavaScript rather than on the backend via Java. The backend will exist mostly for communicating with the database and responding to requests from the client (frontend) for manipulating or retrieving data.
I am rather new to RESTful web services, but in the little I have read about them, I think this might be a good direction to take this project.
I am wondering how I can employ both an MVC framework and REST framework together? Do they make sense together?
I am using Jetty as my web server, so I think that lends itself to using Restlets...?
Anyway, I am not sure how much sense I am making in this post, so I will stop it there for now.
As the previous poster mentioned, it makes perfect sence. MVC let's you separate concerns such that you can keep your application logic separate from your presentational logic.
Your REST controller serves the request you need, populates the model, and exposes it in a REST like manner, typically by returning an xml view to the user. This can be aided by a number of libraries such as xstream, jaxb, castor, xmlbeans, which all provides routines to marshall an object into xml.
Exposing a REST API on the server-side will be a perfect fit for your JS front-end. Your resources will have to expose JSON representations. You will even be able to reuse this web API from other clients such as mobile phones.
As the lead for the Restlet Framework, I can only recommend it for this purpose. Integration with Jetty is very stable :)
Cheers,
Jerome
A quite extensive discussion on this can also be found here:
Separate REST JSON API server and client?
For me it was very helpful.
Yes! It makes sense as Johan Sjöberg said! You can use Spring MVC for example. I like it a lot and think it is very simple and easy to learn. You have an example here.
By the away, for the frontend maybe you would like to check this presentation.
Related
I have an enterprise Java web application deployed in tomcat.
I am looking for ways to integrate a HTML & JS UI with the mid tier java code. So far, from looking around I have read that there are two ways to do this which fit my requirements :
1) DWR - Direct web remoting
2) Use REST web services.
I am not sure which approach to use.
Edit: What is the advantage of using DWR over a rest WS design?
Is there a better approach available? Some people asked me to have a look at GWT, but I am not sure if these are scalable.
Edit 2: I will most likely be using dojo for the UI development(Works well with REST/DWR??), and I want to keep the java code chages minimal. I understand that by using web services, I would have to write an additional WS client layer on top of the existing java code.
Also, the usual enterprise needs, performance, scalability, etc.
Ok so you're building a web client frontend to your java backend, there are a few ways to go about this:
You want to use java standards as much as possible, preferably living in the java EE world: JSF. You will need some knowledge of HTML, XML and perhaps even javascript (though limited). Personally I have had a pretty buggy experience with JSF+richfaces to the extent that I don't use it anymore.
You are very well acquainted with java desktop application development but don't know much about javascript: vaadin: it allows you to write plain java using desktop application terminology which will be compiled to javascript. Currently I am working on a big vaadin project and it is very nice to be working with pure java in eclipse, the downside is however that you are far removed from the actual frontend, so tweaking can be tricky. Additionally everything is stored in sessions (afaik) and scales poorly.
You are primarily a frontend person with unrivaled javascript skills: use a REST interface in java and a pure js/html/css frontend. Personally I think this is the cleanest design and I have designed a few of my own applications like this. The downside is that managing large javascript projects tends to be hard because...well...javascript sucks. The upside is that this will always be the fastest most lightweight option available to you.
Ideologically I would definitely suggest the last approach but this can be hard for large projects. If you have the hardware to throw at it, vaadin is a nice option. My JSF 2 experience was a bit disappointing due to the bugs in (necessary) third party libraries like richfaces.
PS: I have never heard of DWR but the last stable release seems 2 years old and all it seems to do is expose java code as javascript methods which can be better handled with a REST interface.
Open interface standards like REST and SOAP make it easy to build code to consume these services if you are using frameworks to build a REST Client and a SOAP client code respectively. But the point is that you need to have this client code to make calls to these services.
DWR on the other hand, generates this client code. Your java classes are ready to be called (like you would do in Java).
For a new project I want to usa a component-based framework (thinking of Wicket or Tapestry). It's an intranet-application, but i have to provide Restful Webservices aswell.
After googling around i havent found any good solution, that describes how to integrate Wicket with any Jax-RS compliant library.
Has anybody done this before?
I already saw, that Wicket CAN provide rest-like URLs, but i would to switch between fully-fledged Wicket-Gui and webservice by accept-header.
Everything i found, suggests, creating a different vhost/url-route.
If you say, tapestry (or any other framework) is much better, for what i wanna do, let me know. But somehow i like wicket.
I'd recommend using Spring "contract first" web services or REST:
http://static.springsource.org/spring-ws/site/
http://www.ibm.com/developerworks/webservices/library/wa-spring3webserv/index.html
Especially if you're interested in frameworks. Spring is much more than a web MVC framework. It gives you:
Dependency injection
Aspect oriented programming
Rock solid modules for web MVC, persistence, remoting, messaging, security, web services, etc.
I'm not sure why you think a component based approach is superior, but it seems to me that it's been left in the dust by HTML, CSS, JavaScript, and jQuery. I'd reconsider the requirement.
The implementation of the web service should not know or care at all about what technology is used to implement the client. That's the beauty of web services: if done properly, they can survive longer. UIs can come and go, but the business logic and fundamentals in the services can remain. They can deal with UIs running on desktops, browsers, mobile, and maybe even Google's heads-up display. We'll see.
Neither Play, nor Spring MVC is component based.
In Wicket 1.5 you can roll your own IRequestMapper that checks the header(s) and decides whether to use the default processing (component-based) or to use your custom IRequestHandler that will deliver JSON, XML, ... See TextRequestHandler for inspiration. Your custom IRequestMapper should be set as 'root' to be able to get the incoming requests first, see the usages of HttpsMapper and CryptoMapper for example.
Feel free to ask for more details in the users# mailing list.
I am planning to write a medium scale web application. The server side technologies will include Java, Hibernate, MySQL and the client technologies will include Html, CSS, Javascript and Jquery.
I am looking for the best suitable Java framework for developing web (Struts, Spring, Wicket and so on).
I consider myself heavy Jquery user and I really prefer to do client side stuff.
Wicket for example has modules like the date picker and other modules (AJAX) that should make life easIer with javascript and acts like a replacement to it. But I really prefer javascript.
I thought of writing an application with client side and Java Web Services.
What do you think?
Do you know a framework that isn't afraid of Javascript or don't
suggest replacement to it but tools to use it?
Component-based frameworks generally provide ready-to-use components, that come with their own JavaScript code. If you don't like this, I would stick with action-based MVC frameworks, which generally don't care about what you use at client-side.
My preferences go to Stripes and Spring MVC, but YMMV.
I'd recommend the Play! Framework.
It is a MVC based framework and you can use hibernate, work with a MySQL database and it offers templating for easy HTML generation as well as working well with CSS and Javascript (even includes latest JQuery in download). There are also tons of modules you can add to your project to make development faster and easier.
Play 2.0 should be released fairly soon (currently available in beta) which provides support for CoffeeScript and Less CSS (see here) amongst many other new features.
Edit
StackOverflow answer showing how easy it is to create webservices in Play: https://stackoverflow.com/a/4513047/681807
Well all the framework you have mentioned (struts, spring, wicket) , none of them afraid of javascript.
Like in Struts2 and Spring they have provided build in ajax support for developer like me who is more comfortable with serverside development than client side work (ajax/jquery fancy stuff).
Its on individual how he/she is using JS with any existing framework and you are even free to use simple HTML at you client side with whatever JS way you want to apply to your UI.
Framework support to UI is always intended to provide a close integration to the server-side so as to speedup the overall development time.
In Short i can not recommend any framework as that will dependent upon you project requirements which fits perfectly as per your need, but none of the framework will stop you to use JS in the way you want to use.
Looking to implement a RIA using AJAX with Java on the backend.
I was looking at DWR for an RPC style approach, but the project hasn't been updated since 2008.
I was also looking at DOJO and GWT.
Can anyone recommend a core set of technologies that works best for a Java based back end, that contains a rich set of client side widgets and backend integration with Spring WebFlow/MVC?
thanks
I would recommend Spring 3.0. It's up to date, lightweight, easily configurable, supports dependency injection, annotated classes, and is a great framework.
It supports REST, so it's easy to implement classes that return JSON to your HTML pages. This will help keep your content, behavior, and presentation all separate while still enabling you to build a Rich Internet Application.
Although outside the scope of your question, I'd suggest you use JQuery on the frontend as I've had really good results using it to transfer JSON back and forth from the server.
I would stay away from DWR. They merged with Dojo, which in my opinion is a better choice than DWR. DWR sounded good, but in practice it was buggy and difficult to use. Dojo was much cleaner and more modular. But unless you're using Comet (aka Reverse Ajax) just stick with Spring and JQuery.
Spring 3.0 is also supported on Google App Engine... just worth mentioning as Platform as a Service is in our future.
My recommendation is a RIA framework like SmartClient or ExtJS + a REST-based backend (built on Jersey, for example). I have also found JQuery to be extremely helpful when combined with these frameworks. Together. this allows you to build your GUI right on top of a REST API, which itself could be reusable for programmatic integration.
These kinds of questions are always religious ones, but FWIW I am personally not a massive fan of GWT, for multiple reasons. One of those reasons is because I don't want server side folks constructing GUI-targeted data structures (I'd rather have them stick to pure data and let me GUI folks handle the GUI stuff). So I actually don't appreciate that capability of GWT, but obviously many other people welcome that aspect, so again it's a religious choice.
you can try GWT.That supports Spring well.
http://www.springbyexample.org/examples/simple-gwt-spring-webapp.html
If you use a Spring MVC back end, you can use any AJAX frontend there is.
And if you are going to develop a RIA, I would suggest either Prototype with Script.Aculo.Us (Killer GUI effect library) or MooTools (which is either an extension or a re-write of prototype, that also includes many GUI tools).
The great thing about both ProtoType and Mootools is their Object-Oriented methodology (MooTools Class() docs, Prototype Class.create() docs), but the extension mechanism that gives additional methods and properties to DOM elements (How Prototype extends the DOM, MooTools Element reference). Of course this mechanism is exactly what the JQuery guys loathe about these libraries. But the nice thing is that because of these extensions, you hardly ever have to resort to browser-specific programming, the abstraction handles that for you.
I choose JSF for RIA applications.
It is J2EE 6 standard
it built-in in J2EE application servers (glassfish, jboss),
it has several implementations - if you have problem with one, you can switch to another
I has at least 4 (richfaces, myfaces, icefaces, primefaces) independent, big components libraries.
Spring can work well, but my personal preference is for simplicity, and Spring is bit heavy platform. So I prefer deploying services on JAX-RS containers (like Jersey); Guice for wiring things together, and in case I want to override or change data bindings, Jackson for JSON handling.
Other useful pieces would be jDBI for database access (much simpler than hibernate or other full ORMs), async-httpclient for doing calls to other web services.
Best of all, these all work nicely for many other kinds of uses.
I read through a few threads (simple web framework, java web development, etc). Very informative. However I have not seen a focus on the AJAX side of things. For the app I am trying to create, most of the client side will be written in Google GWT, and JSON will be used to communicate with the server side. In that case, all templating is pretty much useless.
For my purposes, which framework would be the simplest to setup and easiest to learn?
Thanks.
To clarify, I want a server side framework. GWT is great for client side, but I need something to generate json responses on the server side.
None at all, most likely: GWT is framework enough, given that's what you're using. The only reason I can think of to add anything else might be if there was some special effect you absolutely craved (but if you've chosen to go GWT, my recommendation would be to give up on such special effects),
Ajax/JS by nature functions mostly on client side and you want to use it but want to run it on server side? Are you sure you're not trying to hammer a square block into a round hole?
Reading through your question it seems to me what you're really asking is for a way to abstract a layer which provides JSON for your client side UI. Most web frameworks such as GWT deliberately abstract this part away but still include it in their inner workings: it would indeed be rather stupid for an Ajax web framework not to support data transfer between the view layer and the rest of the system!
However, if you really want to create your own custom component for serving JSON, then I suggest you take a good look at Servlets and mix that with any of the gazillion available JSON libraries listed at JSON.org.
And if you still really, really want to run your client side view logic on server, Vaadin could do the trick for you. In practice Vaadin really runs GWT on the server side and just serves static stuff generated by the server side GWT but from what I've understood the difference has been abstracted away.
A huge word of warning though, for me it sounds like you really want to reinvent the wheel here while you shouldn't. You really should reconsider your architecture and/or deepen your knowledge of GWT and web frameworks in general, the "framework" part usually hints that it's not just the V from MVC Model 2 but at least V and with M bindings.
I've had pretty good luck with the Dojo Toolkit. Make sure to download the full toolkit (Dojo, Dijit and Dojox) which you'll find at the downloads page.
Their 'Hello World' tutorial is pretty useful for getting started.
You could could give IceFaces a try. It's a Ajax framework based on faces technology. Works really great and magically, also comes with a good documentation and tutorial.
You should look at one of the REST based frameworks, like Jersey, Restlets, or RESTEasy.
The main reason is that these frameworks make binding and working with JSON easy. Most of the other systems are designed for HTTP POST encoded data, which is not JSON.