5
\$\begingroup\$

I have a signup form in which the user has to enter the email address and after some quick asynchronous processing at the backend I have to tell the user that whether the email address is already registered or not.

Below is a sample example of the JSP page that I have created,

<input type="email" id="inputEmail" placeholder="*Email" name="inputEmail" required="true" onchange="checkDuplicate();" onpaste="this.onchange();" oninput="this.onchange();" onsubmit="this.onchange();" autocomplete="off"/> <div id="duplicateEmail"></div> <script> var request; function createRequest(){ if(window.XMLHttpRequest){ request=new XMLHttpRequest(); } else if(window.ActiveXObject){ request=new ActiveXObject("Microsoft.XMLHTTP"); } } //Below 2 functions are to check whether the email entered by the user is already registered or not function checkDuplicate(){ var email = document.getElementById("inputEmail").value; if(email!=""){ createRequest(); var url = "../ajaxPages/check_email.jsp?email="+email; try{ request.onreadystatechange=duplicateEmailMessage; request.open("GET",url,true); request.send(); }catch(e){ alert("Unable to connect to server"); } } } function duplicateEmailMessage(){ if(request.readyState==4){ var x = document.getElementById("duplicateEmail"); var msg = request.responseText; x.innerHTML = msg; } } </script> 

Now the at the backend the check_email.jsp page will be like this,

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %> <%@ taglib uri="http://java.sun.com/jsp/jstl/sql" prefix="sql"%> <c:set var="email" value="${param['email']}"/> <sql:setDataSource var="db" driver="com.mysql.jdbc.Driver" user="root" password="root" url="jdbc:mysql://localhost:3306/ercafe"/> <sql:query dataSource="${db}" sql="SELECT * FROM user_details" var="result" /> <c:forEach var="row" items="${result.rows}"> <c:if test="${row.user_email_id eq email}"> <c:out value="This email is already registered"/> </c:if> </c:forEach> 

I know that it is not advisable to include the database interaction in the JSP page but as this page would be handled in the backend without any direct interaction from the user I'm very tempted to use check_email.jsp as above. Can anyone tell me how to handle the check_email.jsp by the ideal way?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ If you know that it is not advisable, why are you doing it in the first place ? Even if it does not have a direct interaction with the client, it is still in the view component. Why would you add something that look more like a controller or model operation in the view ? \$\endgroup\$ Commented Mar 1, 2014 at 3:24
  • \$\begingroup\$ @Marc-Andre I agree with you but I couldn't figure out how to do this in any other way. It would be extremely helpful if you could guide me through it. \$\endgroup\$ Commented Mar 1, 2014 at 3:26

2 Answers 2

3
\$\begingroup\$
  1. I've never used that sql:setDataSource JSTL tag but the documentation is not promising:

    Creates a simple DataSource suitable only for prototyping.

    Another answer on Stack Overflow says the same: How to use JSTL sql tag.

    (If I have to guess I would say that it opens and close a new database connection on every page load which is a slow operation. Pooling and reusing connections is much better.)

    I'd go with servlets.

  2. This does not scale/perform well:

    <sql:query dataSource="${db}" sql="SELECT * FROM user_details" var="result" /> <c:forEach var="row" items="${result.rows}"> <c:if test="${row.user_email_id eq email}"> <c:out value="This email is already registered"/> </c:if> </c:forEach> 

    The loop iterates over every user_details records. You could add a WHERE condition (like WHERE user_email_id = '${email}' or something similar) but do not do that, I guess it would lead to SQL injection.

  3. alert("Unable to connect to server"); 

    Try to use something more user-friendly feedback mechanism. See: JavaScript's prompt, confirm and alert considered “old-fashioned”

\$\endgroup\$
1
  • 1
    \$\begingroup\$ thanks you cleared lot of doubts through that JSTL example. \$\endgroup\$ Commented Mar 1, 2014 at 14:10
4
\$\begingroup\$

General advice

I know that it is not advisable to include the database interaction in the JSP page but as this page would be handled in the backend without any direct interaction from the user I'm very tempted to use check_email.jsp as above.

It's a good thing when you know that something is wrong to search for a better way to do it. This is an important part of having good code in my opinion.

What you must not do, is code something that you know is not right, but look like having no impact of security or side effects. There is a chance that you won't be the last programmer on this code. What will happen if he decide that the view is more publicly accessible ? (In this case not much since from my understanding, JSP tag are interpreted server-side)

There is one thing you know for sure, that if this code is in the server/controller/service, it will be where he belong!

Re-usability

This SQL request looks to me like a request that could be re-use in different in an application. Will paste it everywhere you need it or would ratter call a service that will return the result of the query ? The second option look better to me.

I can't provide a good example of a service without knowing what framework you use. There is plenty of resource on the internet that could help you, I could point you some tutorials if I could know what your set-up is.

Quick note

In your JavaScript you have var url = "../ajaxPages/check_email.jsp?email="+email;. Are those pages suppose to be responses to AJAX request ? If so, you should know that you can probably create a controller that do respond to AJAX request. In my opinion, this will help you keep all the important logic in the controller and remove some JSP pages that I guess are not doing what they should be doing.

\$\endgroup\$
0

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.