Announcement Announcement Module
Collapse
No announcement yet.
Please share your opinion on this change in Spring v3 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Please share your opinion on this change in Spring v3

    Hi,

    I have been posting comments on Spring 3.0 M1 blog here, here and here. These comments have been answered in a sincere manner by SpringSource people. However, the issue remains to be discussed in a larger context and a professional forum dedicated to Spring MVC seems to be the most apt choice.

    The issue (well, at least IMHO it's an issue) is that in the upcoming version of Spring Framework, the Controller hierarchy is being deprecated and is expected to be replaced by Annotation-driven approach.

    I do not want to make this a long post by writing all my arguments again over here, so I urge you to please go through my comments posted on above mentioned links (and corresponding answers as well, to be fair).

    Let's have an open discussion on this and present our individual views on this. If nothing, at the very least I would like to know what community thinks about this change.

    Thanks & regards,

    - Aditya Jha
    Last edited by aditya_n_jha; Dec 21st, 2008, 10:03 AM.

  • #2
    I've been using Spring for about a year. Version 2 first, and 2.5 since it was released. Annotations may be very useful in some cases, but the problem is that they tie class and configuration. The bad thing is that one class would accept one configuration. If you need 2 different configurations for a class, then you need to make a subclass. This problem does not exist with XML configuration, and the controller hierarchy.

    The second, is that I don't like to bind my code to spring classes. The only exceptions are @Required, and dao support classes, which are really useful.

    Comment


    • #3
      Hi,

      I have been using spring since 2006 varying from 1.x to 2.x

      I feel that deprecating the controller heirarchy is not a very good decision,
      Since There are several patterns that are addressed with the tailor made controllers like AWFC, SFC, MAC and so on.

      I feel that annotations are trying to bring two different worlds together, like coding and configuration, which in my opinion is great for prototypes since you have very less time to showcase your end product or solution to a customer,

      but in the long run I feel that separating configuration and code is always better since people who maintain the software are not necessarily the people who develop it and the people who enhance the software also might not the same developers.

      I dont think Spring Creators should deprecate the controller heirarchy or maybe they should consider supporting various annotations like @SFC @AWFC and so on.

      Comment


      • #4
        This is interesting. The annotations do make the controllers simpler and, with the option to leave out the "configuration" annotations, you still have control over the mappings via configuration. So, for most situations this will be sufficient. Though good documentation about the possibilities around mix & matching of annotations and configuration would be highly recommended.

        However, I see what @aditya_n_jha is saying when more complex operations are required. If you want to use all the annotations, then you will have very little control over the "workflow" in a controller, such as when and if it should perform binding. For example, the ability to perform an operation before binding would currently have to be in the HandlerMethodInvoker#resolveHandlerArguments() method. However there is no hook to allow for a custom method invoker in the AnnotationMethodHandlerAdapter, which kicks of the resolving of the annotated controller methods and arguments. This should be fixed. The use of the private class ServletHandlerMethodInvoker is what makes this so hard to configure.

        Now, even with annotated controllers you can achieve workflow around binding. However to do so, you have to avoid some other annotations, like @ModelAttribute, which is the one that signals the need for a bind. Instead you can take a HttpServletRequest in as an argument, which will be "injected", and perform the binding yourself.

        So, in essence, you can duplicate the Controller#handleRequest method via minimal annotations and still have workflow control. Of course this means doing a little more work yourself, perhaps in an abstract method. However it is certainly doable.

        In conclusion, if HanderMethodInvokers are made more configurable, then I think the only thing that will be lost by removing the Controller interface (and all implementers) is default workflow. You can still build the workflow yourself, which in a complex scenario like @aditya_n_jha proposes, it is probably a good thing anyway. I think the current implementers try to do to much because they have to try and account for every situation. Removing these means less bugs and requests to keep up with and a cleaner framework.

        Comment


        • #5
          What makes Spring a good framework is the fact that it provides a LOT of options. I'm not sure why the developers would want to push a single option onto the users, not everyone is comfortable tying code and configuration and that includes me.

          And I absolutely hate to think of loosing the ability to look at an XML file and see what controller is mapped to what request path.

          Comment


          • #6
            Originally posted by NubKnacker View Post
            What makes Spring a good framework is the fact that it provides a LOT of options. I'm not sure why the developers would want to push a single option onto the users, not everyone is comfortable tying code and configuration and that includes me.

            And I absolutely hate to think of loosing the ability to look at an XML file and see what controller is mapped to what request path.
            Thankfully they aren't proposing to remove this part. You have the option to have request mappings through annotations or XML using the "traditional" HandlerMappings. So, in this case, they are adding another option. One that is especially useful for REST requirements.

            The hard part will be changing the mindset from overriding methods and/or using default controllers to making your own POJO's that have been annotated. Though I have to admit that my own prototyping has made me like the annotated POJO's better (though I'm not too keen on the @RequestMapping with path). Working with a POJO and leaving the hard part to the framework is nice in most scenarios.

            Comment

            Working...
            X