I have some knowledge about Flex and Java EE, they are good for web application development. Anyway when I try to write a typical web page that is based on HTML/CSS/Javascript, I think I should take a look at some new program language/framework.
I heard much good news about grails and finally decided to learn it instead of python, ruby, scale… But I still don’t have an overview of the whole structure. Grails is a backend framework like php, jsp, jsf right? So that probably means, it’s a replacement of Java EE in backend, then how about the frontend (need ajax functionality), what are people using with grails?
thanks
Grails is not a replacement, it is an abstraction around the tradition Java EE stack and some extremely popular libraries like Spring and Hibernate, that allows you to go faster by using "convention over configuration".
One component of Grails is GSPs, groovy server pages, which is a front end technology, the V in the MVC (Model View Controller) paradigm. You also have Domain Objects, which are the M (Model), and Controllers, which are the C. Grails also has Services which are best put into the M category (IMHO) of the MVC paradigm. So the Model arrangement in Grails gives you relatively easy persistence (using hibernate under the covers), the Services give you great reusability in your business and transactional logic, and the Controller simply invoke the right logic for a given request, and return the response.
One part of that response is what gets displayed on the screen. In a simple webapp, GSPs fill that role -- the controller tells the browser to render a specific GSP which has data bound to it from the service method that was invoked in the controller. However, it is easy to have the controller return json, so if the endpoint bound to the controller is an ajax request, the client can handle the response itself.
You can use any front end technology you want in a grails app. The default is GSPs, which is an extension of JSPs, which are part of the traditional java stack, but you can use jQuery, Sencha, Sproutcore, Backbone, anything you want. You would have one GSP in that case which bootstraps your javascript code, and the rest would be handled by the client application.
Grails is a web framework and is not just a backend framework. It supports both JSP and GSP ( Groovy Server Pages) for views.
If you plan to use Ajax functionality, you can make use of one of many javascript frameworks available. You can also go ahead with Flex (since you already know it) or use a javascript framework like ExtJs, Dojo, YUI etc...
Related
I have a design problem at hand. Traditionally I had been developing Spring MVC/Struts/jsf applications with either REST/SOAP service serving the data.
Now we have HTML5 and other javascript frameworks. In this light, do we still need to create Spring MVC applicationS as such (assume that the data is served from a RESTful service)
If I go ahead with pure HTML5, CSS UI (with Ajax calls to RESTful services), what are the possible issues that I may get into? does this approach have security holes like being prone to cross site scripting?
Is it a good approach to start off with? Would this approach be called a single page app?
You still need to serve your single page app from somewhere, along w images and css files. This could be a Spring MVC servlet, or whatever.
I'd look into Spring Data REST which is a servlet that creates RESTful HATEOAS endpoints for you.
It's probably easier if your SPA and REST service are on the same domain, so you don't have to worry about cross-domain restrictions.
They are still vulnerable to XSS, as is any system unless you take counter-measures. Spring security can help here. Make sure you follow the OWASP guidelines.
Use Hibernate Validator's #SafeHTML annotation to prevent unsafe HTML input into your database. Use Spring Security's <content-type-options/> , <xss-protection/> , and <header name="Content-Security-Policy" value="..."/> settings to help fight XSS.
Spring MVC, Struts, etc. provide two core functions: Routing, and Binding.
Routing is dispatching an HTTP request to the relevant piece of code.
Binding is converting the world of Strings that the HTTP request sends you in to something more useful, such as a generic Java bean with not just Strings, but integers and dates.
Along for the ride are aspects such as validation.
Finally, they provide an environment that's particularly friendly to your view layer.
None of these aspects, per se, are obsolete in a world where all you have is JSON coming up and JSON heading back. You still need routing, but now you may care to route not simply on the request url itself, but on HTTP verb. You still need binding, having the framework marshal the JSON payload into some easier for java to work with is very handy.
But, (and I speak in general terms, not specifics as I don't know Spring or Struts well at all), while the MVC frameworks can fill the role of a backend system for a more JSON oriented and raw HTTP world, the specific REST frameworks do the job better.
There's no mistake that the MVC frameworks were a significant step up over raw Servlets. Raw Servlets are functional, but simply too primitive for real work. But with design decisions made from a world 10 years ago, some parts show their age and get in the way in the new world of more raw HTTP requests.
If you're doing a mixed app, some MVC, and some HTTP/Ajax methods, then it's better to work with your MVC framework than adopt a new one.
If you're doing a pure singe page app, then it's worth your while to adopt a framework that tends to that niche. They'll simply be a better fit.
Mind, also, they can live side by side. You can have both co-habitate in a single WAR if you wish, particularly if you're adding SPA features to a legacy application. It doesn't have to be an either/or situation.
But I wouldn't introduce an entire new infrastructure component simply to handle a couple of ajax calls. In the end, they're just HTTP calls, and the MVC frameworks (in contrast to most component frameworks) do just fine with raw HTTP for the most part.
I am currently studying Java EE with Hibernate for a project. In The Web App I am creating I am planning to Ajaxify page contents, and Site wide audio player(Which I think would be implemented using AJAX).
I am using a JSP based MVC, no frameworks, Just Java EE and Hibernate. And I've heard that I need to use a Framework like JSF to be able to AJaxify may web-app. How true is this? Do I really need to learn JSF or other frameworks to be able to Ajaxify my web app? As much as possible I do not want to learn a new framework for now since it is a big learning curve. but if there's no other way to Ajaxify my web app, I'll study a framework.
You don't have to adopt any framework to use partial page updates and similar, you can construct and send requests "manually" with JavaScript, but this is much more tedious then using a framework like JSF, maybe coupled with a component library like primefaces.
EDIT: you can find an abundance of examples of ajax capabilities in the primefaces showcase. Primefaces uses JQuery internally.
EDIT2: I have found some resources on how to dispatch ajax requests with JQuery from a JSP page (I assumed that using JSP was almost equal to not using a framework ;)): here and here. I hope this is what you were looking for.
To add on #Kostja's answer -
I totally agree with him, with Ajax you just need to have a servlet to handle the HTTP requests, and proper JavaScript code.
Besides JSF,I would also consider to look at Apache Wicket - you can read here how Wicket handles Ajax.
The reason I'm suggesting Wicket is that it's more comfortable to some developers to work with somewhat more "component oriented" (swing-like) framework.
I've inherited an incomplete but small web project (Java EE 5, running on WebSphere 7).
The project consists mostly of JSPs that are accessed directly via their URL, and most JSPs look up their own reference to the EJBs (services) they need. Also, there's a Servlet for every form that gets submitted by the HTML code in the JSPs.
Architecturally speaking, is there anything wrong with this?
I was thinking it would be better to have an MVC design. I don't want to convert everything to JSF because I don't want to convert all the HTML and embedded Java scriptlets into JSF tags and managed beans.
I don't really want to use Struts or Spring MVC because they're not part of the Java EE 5 toolkit that comes out of the box with WebSphere, and I don't want to add additional complexity with the additional libs and config files.
I was thinking about building my own little MVC with a "ControllerServlet" that accepts a command and dynamically build and execute the command object, and redirect to the JSP view.
But I ask myself again, is there anything "wrong" with JSPs that post to Servlets? It's actually kind of elegant in its simplicity.
What do you think?
Any suggestions are GREATLY appreciated! Rob
You're asking a rather subjective/localized question. But ala.
There's technically nothing wrong with individual JSPs that submit to individual servlets. The only real problem is when the servlets turn out to contain duplicated code for quite common tasks like collecting request parameters, converting/validating them, setting bean properties, invoking actions, performing navigation. That is not DRY and is what a MVC framework with a single front controller and a well definied lifecycle is supposed to solve.
Or, if the servlet's tasks are actually well refactored with homegrown code to perform those common tasks, then this is in turn not very maintainable as no one else than the original developer knows the ins and outs of this custom framework. So it's hard to find anyone else willing to maintain this webapp without learning another framework again which the new developer wouldn't likely to see in other future webapps. That is why companies usually adopt an existing and well-developed MVC framework like JSF, Spring MVC, Stripes, Struts, etc.
An application is both JS intensive and has a complex business logic +huge data flow that uses backboneJS to structure JavaScript code and there is a necessity for the server side MVC also (Spring in this case).
Is it a good idea to implement server side MVC (spring ) along with client side MVC (backbone) and are there any compatibility issues between them?
In case both can be implemented.How am i going to coordinate the spring views with the backbone view.
How will client side MVC with template engine collaborate with 'View' of Spring.
Though this question has been asked before, I could not find suitable answer for this. Can somebody help me with a detailed answer?
Backbone.js is primarily used for SPA's (Single Page Applications). Your backbone.js segments ('views') are rendered and re-rendered by data, that is fetched or changed. If your application is going to be javascript intensive, backbone is a great minimal framework that will help organize your application. However, backbone is not so simple when your javascript application becomes quite large. You have to have a thorough understanding of the fundamentals of javascript and have a programming decided pattern. Otherwise you application can become quite a mess even with the use of backbone.js.
Anyhow I digress. Think of you client side application (backbone.js driven) completely separate from your server side application (MVC driven). All your client application needs from your server application is the data. That is why backbone.js is built around a REST API. If you are looking to develop a large javascript application, I would look at using MVC 4's Web API for your REST API, and backbone.js to help organize and standardize your client application.
This article describes how to make an application architecture with both server side MVC and JS MVC , respecting the MVC pattern.
http://blog.javascriptmvc.com/?p=68
I'm developing a webapp with Hibernate+Spring 3 (Spring MVC, JSP): I'd like to create some divs with AJAX style (i.e. no need to refresh all the page, independent update of each div).
I'd like a good advice about which AJAX library to use (in conjunction with Spring 3 MVC + JSP) and, if possible, where to find some code snippets.
I know very little of AJAX libraries, JSONs and how to integrate them, but I have good knowledge of Javascript and Spring (and how callbacks work). I'd like to write as less code as possible, particularly in the jsps.
My Webapp will display an updated (every 5 minutes) POJO in a div and perform some operations between different domain objects in the other div when user press a button.
This is correct use JQuery
Here
http://blog.springsource.com/2010/01/25/ajax-simplifications-in-spring-3-0/
you can find working examples to use Jquery+JSON+Spring MVC.
and this question can help you with server side configuration:
JQuery, Spring MVC #RequestBody and JSON - making it work together
I would suggest jQuery. It is very easy to use and has very good ajax support.
In addition to that it has quite a lot of plugins and components.