[Spring MVC] Inclure une Servlet | Creation de menu web dynamique

Version imprimable

07/03/2008, 15h42
Invité

[Spring MVC] Inclure une Servlet | Creation de menu web dynamique

Bonjour,

Dans un développement Web, j'ai une barre de menu conséquente. Cette barre se charge en fonction du profil de l'utilisateur.
Actuellement j'ai une seule page JSP dont je fais un 'include' en haute de chaque page.

Pour obtenir une barre de menu "dynamique" en fonction du profil, je pense me créer une classe "MenuFactory" qui serais chargée de me créer mon menu et de me le rendre dans une String.

Pour que cela sois bien propre je pense écrire une Servlet qui étendrais ou contiendrais "MenuFactory" et que j'incluerais à la place de ma JSP actuelle.

Mais je ne sais pas si il est possible d'inclure une Servlet. J'ai bien tenté d'utiliser les mamppings de mon dispatcher mais cela ne semble pas fonctionner (ce qui me semble normal).

Avez-vous une idée de comment inclure une Servlet via l'instruction "<%@ include file="../includes/menu.inc.jsp"%>" ou sur une autre façon de gérer le menu ?

Merci

Edit : Il semblerait que faire un include d'un Servlet simple fonctionne : http://www.thescripts.com/forum/thread17106.html mais j'aimerais profiter de Spring..
10/03/2008, 11h21
coyote999

JSP = servlet

Une JSP, une fois compilée est une servlet. Donc en toute logique je ne vois pas pourquoi tu ne pourrais pas faire une include de ta servlet...

As-tu essayé d'appeller ta servlet dans ton include ?

Bonjour,

Oui bien sur j'ai essayé mais la servlet n'est jamais trouvée, j'ai essayé avec différents 'pattersn' d'accés à la servlet dans mon web.xml mais le serveur ne trouve jamais la Servlet..

Mon "context" est le suivant.
Je dois pouvoir faire un include de cette Servlet/Page ou que je sois dans l'application. Pour l'instant je me contentais de faire un <@ include file="../includes/menu.jsp" /> et de changer le chemin d'accès à la jsp en fonction de l'emplacement mais ici il semble que je ne puisse faire l'include qu'en renseignant "/MenuServlet" mais Tomcat ne trouve jamais la ressource :cry:

Mon web.xml :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 <servlet> <servlet-name>menuServlet</servlet-name> <servlet-class>be.me.MenuServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>menuServlet</servlet-name> <url-pattern>/MenuServlet</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>menuServlet</servlet-name> <url-pattern>/*/MenuServlet</url-pattern> </servlet-mapping>
et l'inclusion :
Code:

1 2 <%@ include file="/MenuServlet" %>
et enfin, la réponse :

Citation:

org.apache.jasper.JasperException: /WEB-INF/views/jsp/home.jsp(1,1) /WEB-INF/views/jsp/includes/menu.inc.jsp(2,0) Le fichier "/MenuServlet" n'a pas été trouvé
org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler.java:40)
org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:407)
org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:88)
org.apache.jasper.compiler.Parser.processIncludeDirective(Parser.java:334)
org.apache.jasper.compiler.Parser.parseIncludeDirective(Parser.java:367)
org.apache.jasper.compiler.Parser.parseDirective(Parser.java:468)
org.apache.jasper.compiler.Parser.parseElements(Parser.java:1426)
org.apache.jasper.compiler.Parser.parse(Parser.java:133)
org.apache.jasper.compiler.ParserController.doParse(ParserController.java:216)
org.apache.jasper.compiler.ParserController.parse(ParserController.java:103)
org.apache.jasper.compiler.Compiler.generateJava(Compiler.java:167)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:306)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:286)
org.apache.jasper.compiler.Compiler.compile(Compiler.java:273)
org.apache.jasper.JspCompilationContext.compile(JspCompilationContext.java:566)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:317)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:320)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:266)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
org.springframework.web.servlet.view.InternalResourceView.renderMergedOutputModel(InternalResourceView.java:167)
org.springframework.web.servlet.view.AbstractView.render(AbstractView.java:239)
org.springframework.web.servlet.DispatcherServlet.render(DispatcherServlet.java:1158)
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:900)
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:808)
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:476)
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:431)
javax.servlet.http.HttpServlet.service(HttpServlet.java:690)
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)

Je soupçonne le /WEB-INF/ de me poser quelques problèmes..

30/03/2008, 21h40
yostane

bonjour
moi je te propose de charger le profil à partir du contrôleur, et de l'inclure dans ta vue unique comme modèle.

au fait, tu pourrais me passer les méthodes que tu utilises pour trouver le profil d'un utilisateur. mon tp porte sue ce sujet (profiling sémantique)

merci
08/04/2008, 09h52
Invité

C'est, à terme, ce que je ferais mais je voudrais inclure une servlet dont le rôle serait de générer le menu en fonction du profile..

A mon avis le problème que tu rencontres est plutot lié à un mauvais chemin d'accès à ton menu...?

Code:

<%@ include file="/WEB-INF/vues/includes/header.jsp" %>

Voilà typiquement le genre d'inclusion que je fais et je ne recontre pas de problème ... A moins que je n'ai pas bien saisi ton problème....

Rien ne t'empêche par la suite de gérer ton menu via un Controller et de faire dans tes pages JSP un include de ton menu. Par exemple :

Code:

1
2
<%@ include file="/WEB-INF/vues/includes/header.jsp" %>
<%@ include file="/WEB-INF/vues/includes/menu.jsp" %>

La suite reste une histoire de paramêtrage dans menu.jsp (afficher tel ou tel menu en fonction d'une variable dans le modèle passé en paramètre par ton Controller...

En poussant le vice, on pourrait même imaginer un Intercepteur :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
package mova.logging.web;
 
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import mova.logging.service.UserManager;
import org.springframework.web.servlet.HandlerInterceptor;
import org.springframework.web.servlet.ModelAndView;
 
/**
 *
 * @author Mohicane
 */
public class UserLoadingInterceptor implements HandlerInterceptor {
 
    private UserManager userManager;
 
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object command) throws Exception {
        return true;
    }
 
    public void postHandle(HttpServletRequest request, HttpServletResponse response, Object command, ModelAndView modele) throws Exception {
        modele.addObject("user", userManager.getCurrentUser(request));
    }
 
    public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object command, Exception error) throws Exception {
    }
 
    public UserManager getUserManager() {
        return userManager;
    }
 
    public void setUserManager(UserManager userManager) {
        this.userManager = userManager;
    }
 
}

J'utilise ce dernier parce que dans toute mes pages je veux référencer l'utilisateur courant ... cela me permet par exemple d'afficher dans toute mes page dans le header "Bienvenue {nom de l'utiliseur}"

Pour la configuration d'intercepteurs c'est pas bien compliquer:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
<bean id="urlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
        <property name="interceptors">
            <list>
                <bean id="userLoadingInterceptor" class="mova.logging.web.UserLoadingInterceptor" autowire="byName" />
            </list>
        </property>
        <property name="mappings">
            <props>
                <!-- Mapping pour le loggin d'utilisateur -->
                <prop key="/login.html">loginController</prop>
                <prop key="/subscribe.html">subscribeController</prop>
                <prop key="/valider.html">validerInscriptionController</prop>
                (...)
            </props>
        </property>
    </bean>

Je pense que tu sauras te débrouiller avec ça?

Mohicane

11/04/2008, 09h37
Invité

Je fais déja comme cela. Ce que je n'aimais pas c'était l'idée de génére le menu depuis une JSP (car il y à plus de code que d'affichage).
En fait en utilisant l'autre directive d'inclusion, ça fonctionne sans problèmes.

Pour mas pars je préfèrais placer l'utilisateur en Session et pas via un intercepteur.. Mais dans mon cas que je vais utiliser ACEGI pour la sécurité de mon application, il se charge donc pour moi de cette "gestion" de l'utilisateur.

Merci
11/04/2008, 15h22
Mohicane

Ah tiens tu m'intéresses là ... Tu as chargé l'utilisateur en Session via Acegi?
Il y a peut être un truc à côté duquel je suis passé alors avec Acegi. Tu peux m'expliquer comment tu t'y es pris?

Merci d'avance

Mohicane
15/04/2008, 09h09
Invité

Je découvre seulement Acegi mais il semble qu'il mette bien un "utilisateur" en session. Il te suffit de lister les paramètres de la session et tu veras qu'il y à une clef acegi. Je crois qu'il y place à objet à lui (UserCredentials ou quelque chose du genre)

Personnellement dans toues les applications que j'ai vu et/ou développé on plaçait l' "Utilisateur" en session.
18/04/2008, 14h56
Invité

@Mohicanne Voici une réponse à tq question, directement trouvée chez Acegi.

Citation:

Last but not least, sometimes you will need to store the SecurityContext between HTTP requests. Other times the principal will re-authenticate on every request, although most of the time it will be stored. The HttpSessionContextIntegrationFilter is responsible for storing a SecurityContext between HTTP requests. As suggested by the name of the class, the HttpSession is used to store this information. You should never interact directly with the HttpSession for security purposes. There is simply no justification for doing so - always use the SecurityContextHolder instead.