I've written the bare bones of my application using the MVC pattern. I don't currently have any AJAX functionality in my application but I was looking for suggestions on how I would change the architecture of my application to achieve this, to that end I'll try my best to describe my current architecture:
I have a controller servlet "controller.java" which reads the servlet path i.e. request.getServletPath() to determine the action required
I have a number of different Enterprise Java Beans (EJB 3.1) which handle the business logic and which are called by my controller servlet depending on the action requested
I have a number of views which relate to different aspects of my application to which the request is forwarded (by the controller servlet) based on the action requested (i.e. request.getRequestDispatcher(url).forward(request, response);)
I understand that the current architecture could support AJAX functionality (by matching a pattern from my "controller.java" servlet) but I'm getting to the point where I have a huge number of actions supported by my controller and it's getting messy.
Does anybody have any suggestions?
Is there a standard pattern for doing this? I'm trying to stay free of any frameworks just now as I'm a relative beginner! :-)
Thanks
If your controller supports a huge number of actions - it's where you need refactoring. In general your architecture looks correct, if the number of actions is reasonable (up to 10, I would say) per each controller.
One possible way of refactoring is to group controllers into modules.
You can check for ajax requests as follows:
boolean ajax = "XMLHttpRequest".equals(request.getHeader("X-Requested-With"));
and then handle the kind of response accordingly. I.e. returning the view ID which is to be used in a forward or redirect, or returning some JSON which is then to be written to response body, or returning a special View object which contains this kind of information. Given this basic MVC example, it should not be that hard to expand it with ajax support.
Same idea with BalusC.
We have an MVC app that runs by itself. Now to add AJAX functionality we added JQuery and used jqGrid in the presentation layer. It communicates with the backend via AJAX. If we remove the JQuery and jqGrid, we still have a fully running MVC app.
I've put a demo of that at http://krams915.blogspot.com/2010/12/jqgrid-and-spring-3-mvc-integration. Here we integrated Spring MVC 3 and jqGrid/JQuery
Related
I am building my first spring boot project with java in intellij. When capturing form data from an HTML page, is there a 'best practice' way of transporting the data to the server controller as a JSON request body? I've seen solutions with javascript / ajax, but I prefer something more native to the spring library.
There are two ways.
Setting your Back-End as a REST API and completely separate your Front-End and communicating through REST calls. (as you said with JS/Ajax)
Setting your complete app under one roof. Spring and Thymeleaf are a good option. It works like this, every time you do a /GET request then spring will provide a template. Which is a Thymeleaf HTML document which has Thymeleaf specific syntax to make your life easier.
You can submit your data to your back-end through forms. When you submit the form then your app decides what happens next, will you be redirected somewhere else or will another template be opened...That's your call.
If you want a quick way to do it, go with the second way. Personally, I like the first one. It separates the concerns perfectly.
I've a java based web application running on Tomcat and it uses spring framework. I need to expose a ping URL to check whether the application is up and running. I've considered the following implementation approaches and all of them seems to work well when I tried them. However, I could not make up my mind whether one approach is better than another. Does it matter which path I take? Could someone advise which approach is better and why?
Create a web page and modify web.xml to redirect the url to the jsp page.
Create a REST service using Spring-WS
Create a servlet and return response
Use anything you want :-) But notice, that both Spring-WS and JSP are a little heavier (really not a meaningful reason here) than servlets. If you already have REST API to your aplication, use Spring-WS, if you render pages through JSP, use JSP. Or if you use none of these, write a plain servlet.
Since you are using Spring, assuming you use Spring MVC, you can just add another controller mapped to a certain URL which would be responsible for returning a status.
Solution 1 might not work depending on your requirement since a jsp page might work even if the rest of the app does not since it is not part of spring config.
I would like to know what is the starting point of any web application deployed on JBoss/Weblogic/Webphere.
For example, If you take a struts based application the starting point is ActionServlets plays the role of controller which manages all incoming requests. I am sure controller is depends on framework.
If so, please help me identifying the popular frameworks other than Struts, Flext etc., where I can presume ActionServlet as my controller.
Still a question on back of my mind, Wondering is there anything specific to Application Server? if so, any insight would be highly appreciated.
Thanks in Advance...
After your clarification, I'll try to write down how do I structure simple web apps (without frameworks)
a startup servlet, only initializing global stuffs and checking for resources (db pools, jms). Only it's init() method implemented and loaded with order 0.
a login servlet, with a login jsp as its main view.
a set of welcome pages redirecting the user to the login servlet (in web.xml)
a dashboard servlet, with a simple jsp as a view intrumenting menus and providing a nice starting point for the app.
After this, every action/menu, will map to one or more servlet doing all the bacground stuffs and redirecting to jsp views.
Usually I manage each request into a single servlet, doGet() or doPost() method, but it's not mandatory, depends on what I am doing.
For example, if you have to generate a report and this generation takes time, the servlet simply enque a report request somewhere (JMS queue or starts a Quartz task) and gives back control to the browser with a courtesy page stating that the request has been queued.
There are also scenarios in which a single request from the web UI, functionally impacts more of my "servlets", in such scenarios I chain the requests using the RequestDispatcher utility.
Doing this may lead to code duplication, so a good design of a business class tree is a must. Common business code shared among servlets (which act as the glue between user inputs, business logic and data logic - just like controllers ^^)
I have started working on a Web java learning project.
I am making a webapp and I want to register users to the website:
Whats the best way to implement registration functionality:
Have a register.html and in form call a servlet register which registers the user into database.
Or have a jsp page which does all this or similarly call the servlet .
Or any other..
Please explain the reasons too, that why one is better than other, or why some method should be used or preferred?
Thanks
All three that you cite are equivalent. JSPs are compiled into servlets that are HTML factories.
Yes, you need a web UI.
You'll need a database to persist the data, so you'll be using JDBC.
You'll need some object and relational models representing users and their credentials.
You'll want to read about Model-2 MVC for web apps. It describes an architecture where JSPs interact with a servlet, which delegates to other objects to do the work and redirects the response to the right JSP depending on what happens.
You'll want to read about the front controller servlet.
I will go for option 1 :
"Have a register.html and in form call a servlet register which
registers the user into database."
but with a sort of javascript/jquery validations.
Create a html page which contains form and js to validate form fields and a servlet to make
database entries for newly registered user. Options 2 is also similar with this.
Both the methods mentioned by you are same. Take html page and then call a servlet to persist in database or you take JSP page to do,both are same,as in both you are using servlets.. In both methods you will use server side validation and also handle for SQL injection.
If you are comfortable with any of the MVC framework then try to use it.
JAX-RS has some MVC support, but I wonder if JAX-RS is really a good choice to build web application for human use.
If a user enters wrong or incomplete information in a form, it should be displayed again like with Grails or Wicket. Is there a comfortable way to do this with JAX-RS?
As far as I know the URI mapping doesn't work correctly, if not all required parameters are given or there are type conversion problems (with Date for example). Is that correct?
Is there support for internationalized templates?
Here is an example for a simple JAX-RS based GUI application. But it is really simple and thing like i18n and validation are not discussed.
Yes you can, but you have to clear your head of the old page-post model and start to think of your application as a disconnected UI that communicates with a RESTful SOA. When form data is entered, it post to a service endpoint if the data is not correct then you respond back with an error and the UI handles dealing with that error. You do not post forms to the server in the traditional page-post model but rather you make RPC like calls to your back end system. Your view becomes completely detached from the rest of MVC stack. This makes replacing the view with a custom mobile or IVR system extremely simple.
If a user enters wrong or incomplete information in a form, it should be displayed again like with Grails or Wicket. Is there a comfortable way to do this with JAX-RS?
With a rich internet application you do not have to repopulate data because you never left the page, an XHR call is made to the server and either a success 200 is sent back or an error. The UI then decides what to do based on that response, but the page is still intact because the call was out of band from the main UI thread.
JAX-RS is the Java EE RESTful framework. JavaServer Faces (JSF) is the Java EE MVC framework. It supports all what you've mentioned in your question: postback to same form on error, i8n/l10n and much more. To learn more about JSF, go through Java EE 6 tutorial part II chapters 4-9.
You can do a bit MVC with JAX-RS, but it isn't a full fledged MVC framework. The same story goes on that you can do a bit RESTful with JSF, but it isn't a full fledged RESTful framework.
If you want best of both worlds, I think you really need to head to Ruby on Rails or Groovy on Rails.
Or take the integration approach to get the best of both worlds: JAX-RS + MVC.
The JBoss RESTEasy implementation of JAX-RS integrates with Spring MVC. See http://www.jboss.org/resteasy
Here's a little tutorial on RESTEasy + Spring MVC: http://java.dzone.com/articles/resteasy-spring
There are lots of questions in this one, I'll give my view on two of those.
"I wonder if JAX-RS is really a good choice to build web application for human use."
Web services are usually for machines to interact with, although I would argue it is usually humans that have to programme the interactions - this needs to be compared with SOAP where, at the moment, there is much more scope for machine generated code from WSDLs.
"If a user enters wrong or incomplete information in a form"
then in a RESTful HTTP web service which accepts a html form representation you should return HTTP error 400 because the client has provided a representation that does not conform to the representation your service expects - it is up to the client to deal with the error.
Take a look at ReXSL - it's an MVC framework, on top of JAX-RS. Thus, the answer is - yes, JAX-RS is perfectly suitable for MVC design.
Short answer: YES.
It serves as the base to implement MVC (MVC 1.0 - JSR 371) for JAVA EE 8. The Controller will be a JAX-RS bean with #Controller annotation (on class or methods).
For mor information see: MVC 1.0 (JSR 371)
If you took that path at your time you've done a really good decision, it should make it easier for you to upgrade and use the new Java EE 8 MVC architecture.