I am relatively new to spring. I would like to know if there are any possible ways to automatically poll the database using Spring 4. The user would not need to refresh any pages for the code to fire.
I would need my jsp page to automatically poll the database every few seconds.
I think you are confused about how JSP works. JSP is a graphical facade on Java Servlets, which (normally) take in an http request, and returns some html or an error code. That's the servlet's entire life span... the servlet will re-run with every incoming request.
To do what it seems you want to do, you will need to find a solution in JavaScript / JQuery. A commenter has suggested you look up on AJAX programming - you should take his advice.
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 developing this web app using jsp and servlets. I was wondering how to display results on same page as on from which the request was made. For example, usually what I do is that a request is sent from one jsp to a servlet and then servlet sends the response/results on separate jsp. I am want to show a database results on same page. How can this be done?..A code snippet would be appreciated. Thanks
Just set the necessary data in the request scope and use RequestDispatcher#forward() to forward the control to the desired JSP which in turn can generate the appropriate HTML based on the results.
request.setAttribute("results", results);
request.getRequestDispatcher("/WEB-INF/page.jsp").forward(request, response);
This is also demonstrated in the hello world examples in our servlets wiki page.
That's totally posible, but you need to include JavaScript in your toolset. What I'm suggesting is an AJAX approach in your application, and that implies intensive use of client-side scripting (i.e JavaScript).
This tutorial from DeveloperWorks makes a pure JavaScript/Servlet approach. If you want to do more advanced stuff, I strongly suggest you to use a JavaScript Framework with AJAX support, like JQuery.
From your servlet, send a redirect to your same page. Also, set some attributes in request and show it in your page, e.g. save List<MyObject> in request, then in your jsp read the list from request and show the values in a table.
I have a Java servlet from which I need to send few notifications to the HTML page before I send the final response (which is a PDF file).
Basically I need to keep the user updating on steps I am performing while generating the PDF for them.
I guess, one way could be set various attributes using HttpSession and have them printed using JS. But I don't know how to do that dynamically without loading the page again.
Any idea on how can this be done? I am kind of new to JSP and servlets.
There are two ways:
AJAX polling - you send ajax requests periodically, and the server responds. The page does not get refreshed. Check jQuery for an easy way to make ajax calls
Comet - that's an umbrella term for what you are trying to do. Usually it means keeping an open channel with the server. There are many ways to implement comet (including the option above), but in Java, on the server side, there are two things to check:
Servlet 3.0 asynchronous support
Atmoshphere - chooses the best underlying mechanism provided by the container, which includes the async support above
You should probably look forward to use some implementation of COMET (with js library of choice).
If your html code is allowed to use html5 features, you could also use websockets
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.
I am quite new to ICEfaces but already have experience with JSF/Facelets and the Java EE in general.
Currently, I am not using to much of ICEfaces except some utility tags like outputStyle and outputDeclaration, but even this is really nice to have.
Even though I plan on using some AJAX functionality later, I have some h:forms (or ice:forms) which I would like to send as normal JSF POST requests, without going via /block/send-receive-updates. The reason is, that I want to use a filter, which acts on the requested URI, which is impossible if everything is sent to /block/send-receive-updates.
Is there some way to do this?
Edit: To clarify what I want to do:
The web site we are developing consists of publicly available pages and some which only registered members can access. The standard FORM-based security mechanism as defined in the servlet standard is pretty inflexible, as it only allows to define a single login page which is shown, when someone wants to access some restricted content. Because we also want to user to be able to log in by using a small login form visible on every page, we developed a filter, which handles authentication and authorization almost like the web container. It redirects to a custom login page if the user is not authenticated/authorized, but also allows to authenticate a user from a backing-bean. To make it work almost transparently it wraps the HttpServletRequest to supply the Principal and the user roles.
When the filter redirects to the custom login page it saves the current request to "replay" it later, when the user has been successfully authenticated. To do this, the filter has to be able to detect, if a POST request came from the login page (and thus if the user is now authenticated/authorized). But if every POST is going via /block/send-receive-updates this doesn't work anymore.
Of course I could exclude the login page from being handled by ICEfaces, but this would mean I couldn't use any ICEfaces/AJAX on the login page.
This might not be the best way of doing this, but it might be a way. I'll assume, for the sake of argument, that your header holds your extra login form. If you were to make your header in either a seperate frame or in the main layout page and imbed your JSF pages into an iframe, this might work. The idea being that since it's being rendered as a seperate page, you can handle it in a seperate way.
Also, there might be a different way of handling your security that would make this more IceFaces-y. Perhaps, when you hit the filter and it determines that you're not logged in, it should create a bean (probably session) which holds the information from the original request (URL, parameters, etc.) and the sends you on to the login page. The login page does its thing, adding your security stuff, then uses the information in that session bean to force a redirect to your new page. You can use the FacesContext to get your HttpContext and do a redirect. You'd probably need to play around with the redirect to add any appropriate parameters. Lastly, you should get rid of the session bean.
Finally, I know that there are a couple of Frameworks (Spring WebFlow, springs to mind) that will save your request state, let you do the login, and redirect you back to where you were going in the first place pretty seamlessly (which, reminds me, I think Seam can do this too. Probably Orchestra and your other frameworks as well.)
Hope this helps!
I've been using IceFaces for nearly a year now and haven't yet come across any way of submitting the form without going via send-receive-updates. But I'm curious, you say "I plan on using some AJAX functionality later". The point of IceFaces is that it pretty much transparently adds AJAX to your JSF app. It's an "all or nothing" kind of thing - any page you have which uses IceFaces will use AJAX.
The only thing I can think of you could do is not use IceFaces for the pages you want to use POST requests on - i.e. you could map IceFaces pages to *.iface, but normal JSF to *.faces.
Alternatively, there may well be some other way of accomplishing what you want to do with filters.