【问题标题】:Spring MVC - using Poincuts to fill Spring MVC partials with dynamic dataSpring MVC - 使用 Poincuts 用动态数据填充 Spring MVC 部分
【发布时间】:2012-06-15 05:26:55
【问题描述】:

如何在 Spring MVC Web 应用程序中使用动态数据(如用户名)填充可重用部分(如标题),每次调用一组控制器(页面控制器)但不为其他控制器(表单控制器、ajax、.. .)?

标题:

<#import "../spring.ftl" as spring />
<!DOCTYPE html>
<html>
<head>
<title>DW-Client</title>
</head>
<body>
<h2>Welcome ${menu.userName}</h2>

索引:

<#include "common/header.ftl">
<!-- stuff -->
<#include "common/footer.ftl" />

这是对this SO post 的一种跟进。然而,这家伙似乎不再活跃,我想听听一些关于我们用动态菜单之类的数据在 spring mvc web 应用程序中填充部分的方法的新意见......

另一个人建议使用AbstractController,它被所有页面控制器扩展并通过@ModelAttribute 注释方法填充变量,这似乎是一个不错的主意。但我最初的想法是:

为什么不使用带有切入点的 AOP 来填充 ModelAndView.model 只需使用 @MenuData 来注释控制器或方法。现在,每当调用控件时,它都会被向 ModelAndView 添加所需信息的 Aspect 拦截:

@RequestMapping(value = "/")
@MenuData
public ModelAndView homePath() {
    ModelAndView mav = new ModelAndView();
    mav.setViewName("index");        
    return mav;
}


@Target({ ElementType.TYPE, ElementType.METHOD })
@Retention(RetentionPolicy.RUNTIME)
public @interface MenuData {
}

@Aspect
@Component
public class MenuDataAspect {

    @Inject
    private MenuDataProvider menuDataProvider;


    @Pointcut("within(@MenuData *) && execution(public * * (..))")
    public void menuDataRequested() {            
    }

    @Around("menuDataRequested()")
    public Object provideMenuData(ProceedingJoinPoint pjp) throws Throwable {
        Object output = pjp.proceed();
        ModelAndView mav = (ModelAndView) output;
        mav.getModel().put("menu", menuDataProvider.getMenuData());            
        return mav;
    }

}

现在我应该可以在我的部分标题中说${menu.userName} 或任何内容...这样我可以准确控制哪个控制器应该有menuData。

通过告诉切入点拦截所有以 Page 开头的控制器,可以使这个概念更加灵活(不确定语法,但我知道它会起作用,例如 @Pointcut("within(*.Page*)") 或 pageController 包中的所有控制器或随便。

当然,也可以为不同的菜单场景定义多个注释,这些注释不依赖于会话,而是依赖于页面。


所以我想知道,这种方法看起来是个好主意还是有什么陷阱?你会做什么不同/更好?您使用哪种方法?

谢谢!

【问题讨论】:

    标签: java spring model-view-controller spring-mvc aop


    【解决方案1】:

    在一些控制器类中初始化数据时,AOP 似乎有点矫枉过正。

    我质疑 (a) 不是应用程序范围的行为,(b) 仅限于少数用户页面级控制器,以及 (c) 可以使用传统继承来实现的复杂性。

    虽然它在技术上可行,但使用继承的令人信服的理由是什么?

    如果我在这方面提供过多的信息,你就必须更加努力地卖给我。

    【讨论】:

    • 是的.. 好点我猜.. 我可能在潜意识中偏向于反对继承和专业的自定义注释.. 但你对复杂层是正确的.. 没有注意到,因为那些切入点非常基础和简单,但它可能很快就会失控..
    • @Pete 我对继承也不是很感兴趣,但在许多情况下,它可以精确地模拟需求——尤其是在这样的情况下,在应用程序之外没有真正的重用,并且非常浅的(如果有的话)继承层次结构已经到位。然而,我,在通过更传统的方式实现微不足道的功能时,我反对AOP——而且我喜欢 AOP,很多 i>.
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-01-02
    • 2018-02-22
    • 2012-12-04
    • 1970-01-01
    • 2018-05-05
    • 1970-01-01
    相关资源
    最近更新 更多