Announcement Announcement Module
Collapse
No announcement yet.
Design advice for centralising code for all controllers Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Design advice for centralising code for all controllers

    Hi,

    I'd like to seek design advice using Spring MVC as I have a requirement that is complicated by Spring's different super-classes for various types of request processing.

    Essentially, a user navigates their way through our site. Our site is dynamic, as is our page tree. Each click on our navigation maps the URL to a row in our pages table to obtain page specific properties, content assets and so fourth. Fairly traditional I would say.

    For this purpose we map almost everything in terms of navigation to a PageController. This controller uses services to obtain the relevant page.

    The problem I am facing is that sometimes we need to write other controllers, such as those that extend SimpleFormController, or perhaps those that require the use of AbstractCommandController etc. Every time then that we need to do this, the stub functionality within the PageController that calls page services to obtain the page information needs to be duplicated.

    I am not happy with this status quo. In Struts I have solved this there are not a range of super-classes to extend, so I define a base class that is called by the Struts framework, does it's bit for all Action sub-classes and then calls an abstract method to get the actual Action to do its job.

    With Spring, this does not seem to be as easy. I would have to create my own Base class for each request controller type in the Spring API (at least this is what I think).

    Can anyone offer the best approach to centralising some operations that ALL controllers need within the Spring framework, in particular noting that we do need to use all types of Spring controllers?

    Thanks and regards.

  • #2
    We have a similar problem where we need to place common model information and/or audit functionality in a large number of our controllers (of course there are always exceptions :wink: ) We've solved this issue through the use of interceptors.

    Comment


    • #3
      Are you able to point out a few of the objects/interfaces involved in your interceptor solution?

      In particular, are you able to access services/daos from within interceptors, i.e can these be injected from the applicationContext?

      Thanks very much for the tip.

      Comment


      • #4
        I have a similiar feature where every "page" has an associated DB object.

        I currently have a filter which loads the object and sets it on the request.

        Comment


        • #5
          I've read up on AOP in Spring in Action and it looks very cool. Not sure if it's a little OTT for what I need. I already have a RequestFilter and I've decided (and tested) getting my page object populated into the request at this point which seems to work as I need it to, so unless there is specific advice to the contrary of using a filter, I will stick with this.

          Thanks.

          Comment


          • #6
            Well it isn't as cool

            Comment

            Working...
            X