Best design for reusing view logic?

[martinl]

How about using Spring AOP for this? I.e. using a proxy/interceptor that adds the required view data to the ModelAndView object after the handle...() method?

[Andrew Swan]

... I wouldn't have thought that deciding what model data goes into the view was an aspect. If I understand correctly, aspects are non-functional concerns like logging and security. However this issue (how to assemble the view data) is more like core application functionality, and therefore not an aspect.

I'm still subclassing ModelAndView for assembling non-trivial view models in a reusable way, and I'm still liking it. But please keep those thoughts coming, I'm always keen to know how other people are approaching these things!

[Colin Yates]

Good question

Depending upon where you get this information from, I would probably implement a delegating http://www.springframework.org/docs/...vlet/View.html, i.e.:

  public final class SensibleNameView implements View {
    private View view;
 
    public void render(final Map model, final HttpServletRequest request, final HttpServletResponse response) {
      Map newModel = populateModelWithYourObjects();
      newModel.addAll(model);
      view.render(newModel, request, response);
    }

    public void setView(final View theView) {
      this.view = theView;
    }
  }

The reason I think View is a better candidate than ModelAndView is because you are not changing the behaviour of ModelAndView, so you don't want a new kind of ModelAndView, whereas you are changing the behaviour of a View.

In other words, I wouldn't override a Map simply because of what I stored in it Just my opinion

[Andrew Swan]

Thanks yatesco, that's a further refinement - like it, like it!

It's interesting however that nobody has yet come out and said "yes, I have exactly this problem and here's what I do... etc.". Of course it's great to receive intelligent suggestions, but the fact that nobody seems to have already crossed this bridge for themselves tells me I might be heading down the wrong path (if that's not stretching the road metaphor too far). It's mildly worrying to be beating a new path for what I would have thought was a pretty common problem.

[Colin Yates]

I kinda have the same problem in that every request has a corresponding user and a page.

I load these objects in filters and set them as request attributes. Then in my jsps there is *always* a ${user} and ${page}. I also have filters which do the right thing with regards to user not found, permissions (403) and page not found (404) etc.

Works for me, and allows my "core" code to make assumptions. But, the user and the page are easily located from the request....

[adamjk]

Yatesco,

Struts Tiles might be a good solution to always retrieving particular objects for a set of views
Check out http://struts.apache.org/userGuide/dev_tiles.html
and for spring integration http://static.springframework.org/sp...tml#view-tiles

Apologies if you knew of this already.

Adam

[Colin Yates]

adamjk; thanks for the links.

Not sure how applicable they are to my problem though I do use tiles to manage a set of fragments which I combine into a single page, but I don't think tiles offers any solutions to *retrieving data*.

Maybe you misunderstood my problem I do not need to *display* the same information all over the place, I just need the data to be accessible.

I *could* (but wouldn't recommend it) use tiles to always include some jsp fragment which retrieved the required data using scriptlets but no

HTH.

[Andrew Swan]

Does using Tiles also mean you have to use JSPs (shudder) ?

[adamjk]

I don't believe that Tiles requires using JSP. There is a jsp tag library for Tiles, although Freemarker is able to leverage tag libraries.

For spring integration, the viewResolver bean should have a viewClass of TilesView and this inherits from InternalResourceView which is used for JSPs, afaik. I'm not sure of the details but I would suspect that you'd have to write a TilesView that extended the appropriate view technology (e.g. FreemarkerView, VelocityView).

Adam

[jgangemi]

... I wouldn't have thought that deciding what model data goes into the view was an aspect. If I understand correctly, aspects are non-functional concerns like logging and security. However this issue (how to assemble the view data) is more like core application functionality, and therefore not an aspect.

I'm still subclassing ModelAndView for assembling non-trivial view models in a reusable way, and I'm still liking it. But please keep those thoughts coming, I'm always keen to know how other people are approaching these things!

why don't you just use a standard handler interceptor? no AOP required.

you can add whatever model data you need to the view object after it has been processed by the controller. see here: http://static.springframework.org/sp...ng-interceptor