JPA et InnoDB, et JSP/questions JSTL

Question

Quelques questions:

1. Si je cartographié un client avec un i-var List<Order> orders avec annotations CascadeType.ALL, dois-je mettre également la relation MySQL InnoDB ON DELETE CASCADE? Ou vont-ils interférer?

2. Est-il nécessaire de dire <%@page contentType="text/html" pageEncoding="UTF-8"%> dans chaque fichier JSP? Puis-je le définir comme un paramètre de configuration dans web.xml à la place?

3. Est-il possible que le compilateur vérifie pour vous les URL de mappage de servlet et les URL dans la JSP, ou en quelque sorte confirme qu'ils sont synchronisés? Exemple: dans web.xml <url-pattern>/login</url-pattern>, et dans login.jsp: <c:url value="/loginn" /> (notez le n supplémentaire).

4. Quelle est la différence entre <c:out value="${value}" /> et juste $ {value}, les deux semblent fonctionner (sauf si vous voulez une valeur par défaut)? Quand devrais-je utiliser quoi?

5. Y at-il une meilleure façon de valider les paramètres d'entrée (à partir d'un formulaire) dans un 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 
   } 
   

sans-framework web d'une sorte?

Answer 1

1. Pour avoir une bonne datamodel, oui vous devriez.

2. Vous pouvez éventuellement utiliser un filtre qui ne HttpServeletResponse#setCharacterEncoding() et #setContentType(), mais pour les pages JSP clair que je préférerais @page au-dessus de cela. Si nécessaire, ajoutez simplement une ligne supplémentaire en haut du modèle JSP dans votre EDI afin de ne pas avoir à le faire à chaque fois.

3. Non. Ce n'est pas la responsabilité du compilateur.

4. Le c:out échappe aux entités HTML, ce qui n'est pas le cas du format EL dans le modèle. Vous devez utiliser c:out lorsque vous souhaitez réafficher l'entrée contrôlée par l'utilisateur. Sinon EL simple suffirait. Par exemple:

   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! --> 
   

5. Bien sûr, il existe un meilleur moyen. Mais comme vous ne voulez pas utiliser un framework, ça s'arrête ici. Je peux au moins suggérer que la clé est DRY. Minimiser et refactoriser la duplication de code. Essayez également de le rendre abstrait afin qu'il soit facilement extensible et réutilisable. Voici quelques conseils:

   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

1.Non, vous ne devez pas. Les cascades sont gérées par votre fournisseur JPA.

5.No. Écrivez vos propres classes d'utilitaires ou cadres de validation, ou utilisez-en un existant.

Answer 3

4) <c:out value="${value}" /> XML effectue Évasion, ${value} ne pas