Question

A couple of questions:

If I have mapped a Customer with an i-var List<Order> orders with annotation CascadeType.ALL, should I also set the relation in MySQL InnoDB ON DELETE CASCADE? Or will these interfer?
Is it necessary to say <%@page contentType="text/html" pageEncoding="UTF-8"%> in every JSP file? Can I set this as a configuration parameter in web.xml somehow instead?
Is is possible to have the compiler check the servlet mapping url s and the url s in the JSP for you, or somehow enforce that they re in sync? Example: in web.xml <url-pattern>/login</url-pattern>, and in login.jsp: <c:url value="/loginn" /> (note the extra n).
What s the difference between <c:out value="${value}" /> and just ${value}, both seem to work (except when you want a default value)? When should I use which?

Is there a better way to validate input parameters (from a form) in a servlet:

String possibleUserID = request.getParameter("userid");
if(possibleUserID == null){
    errors.add("User-ID must be exist");
} else {
    if(possibleUserID.trim().length() == 0){
        errors.add("User-ID must be filled in");
    }
    // etc
}

without a web-framework of some kind?

Answer 1

To have a proper datamodel, yes you should.
You can eventually use a Filter which does HttpServeletResponse#setCharacterEncoding() and #setContentType(), but for plain JSP pages I would prefer @page above this. If necessary just add extra line to top of the JSP template in your IDE so that you don t need to enter down it everytime.
No. That s not compiler s responsibility.

The c:out escapes HTML entities, the EL in template text doesn t. You should use c:out when you want to redisplay user-controlled input. Otherwise plain EL would suffice. For example:

String input = "<script>alert( XSS );</script>";

<p><c:out value="${input}" /></p> <!-- works fine, no alert, just escaped. -->
<p>${input}</p> <!-- JS get interpreted and executed! XSS! -->

Sure, there is a better way. But as you don t want to use a framework, it stops here. I can at least suggest that the key is DRY. Minimize and refactor code duplication. Also try to make it abstract so that it is easily extendable and reuseable. Here are some hints:

String username = view.getField("username", REQUIRED, MINLENGTH(3));
String email = view.getField("email", REQUIRED, EMAIL);
Integer age = view.getField("age", Integer.class, NUMBER);

// ...

public String getField(String name, Validator... validators) {
    return getField(name, String.class, validators);
}

public <T extends Object> T getField(String name, Class<T> type, Validator... validators) {
    String value = request.getParameter(name);
    return validateAndConvert(name, value, type, validators);
}

private <T extends Object> T validateAndConvert
    (String name, String value, Class<T> type, Validator... validators)
{
    value = (value != null && !value.trim().isEmpty()) ? value.trim() : null;
    try {
        for (Validator validator : validators) {
            validator.validate(value);
        }
    } catch (ValidatorException e) {
        setError(name, e.getMessage());
    }
    return (value != null) ? Converter.convert(value, type) : null;
}

Answer 2

4) <c:out value="${value}" /> performs XML escaping, ${value} doesn t

Answer 3

1.No, you don t have to. The cascades are managed by your JPA provider.

5.No. Either write your own utility classes or validation framework, or use an existing one.

友情链接