This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Other Application Frameworks and the fly likes Your opinion: Spring v3.0 deprecates Controller hierarchy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Frameworks » Other Application Frameworks
Bookmark "Your opinion: Spring v3.0 deprecates Controller hierarchy" Watch "Your opinion: Spring v3.0 deprecates Controller hierarchy" New topic
Author

Your opinion: Spring v3.0 deprecates Controller hierarchy

Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Hi,

As we see in early developer release of Spring Framework v3.0, the Controller hierarchy is being deprecated in favor of Annotation-driven approach.

I'm all for the advancements in language and making it more elegant and usable. However, IMHO this change goes a bit too far. We can't discard a well-balanced hierarchy following Open-Closed Principle pretty nicely, just because there is a new feature in language, especially when usability of this feature has the potential of presenting some other problems.

My arguments on this can be viewed at here, here and here.

I have started a thread on Spring Web forum to understand the community's view on this change. Kindly share your opinion on this thread.

Thanks & regards,

- Aditya Jha
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

I disagree. (sorry had to remove some stuff for other reasons)

You can still use xml for mapping URLs to your controllers and not have to use Annotations. and you can always have xml overwrite what you have in Annotations.

Mark
[ December 22, 2008: Message edited by: Mark Spritzler ]

Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Hi Mark,

1) By using Spring Annotations (which are essentially meta-types in Spring API), we're not really removing tight-coupling entirely. A real POJO should not be having any Spring import at all.

2) Each Controller class is well documented and pretty cohesive. It never puts you in a dilemma, as the purpose of each one of them is unique. To me, its more like the Collections classes, where you have a number of types, however, each with a dedicated purpose and pros & cons.

3) Yes, more classes = increased complexity (at least prima-facie). But also, 'more flexibility'. The template pattern used in these Controller classes give us an unparallel advantage over Annotation-based approach, wherein we can fine-tune application to our very specific needs (for example, deciding how a request should be interpreted as a form-submit request).

The thing is, I'm not at all averse to Annotations being used by community, when they bring simplicity to the implementation. However, keeping ONLY that option open is not going to do good in my opinion. For specific cases, we might still prefer to use some Controller class.

I mean, I can still use a java.util.Vector (and even the elementAt() method in that), if despite what it gives, it suits my bill. There is nothing wrong in this class per se, only there may be more efficient ways to do the same thing.

Labelling controllers as 'deprecated' simply closes that door... somthing I'm not agreeing with at all. For me, annotations are not the answer to ALL the situations.

The reason to deprecate a class or a method in the open world of Java has always been different from simply 'promoting one way over another'. Its more like 'providing a better and more efficient way which caters to ALL what was supported by older version (and probably even more)'. The replacement of a deprecated artifact should also take care of not undermining maintainability (debugging, flow-control) etc.

Best regards,

- Aditya Jha
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

And hey!

"I believe you can have both. and sometimes, in order to have both, you need both."


I totally agree with you on this, and in fact, this is EXACTLY my point.

Best regards,

- Aditya Jha
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Originally posted by Aditya Jha:
And hey!



I totally agree with you on this, and in fact, this is EXACTLY my point.

Best regards,

- Aditya Jha


And there is both. The Controllers are still there, just deprecated. The xml is still there too.

" By using Spring Annotations (which are essentially meta-types in Spring API), we're not really removing tight-coupling entirely. A real POJO should not be having any Spring import at all"

This has been a debate for some. If you think this is not a real POJO, then you also would think that adding Javadocs makes it not a real POJO, because really that is all that Annotations are. Yes, you have an import, which is not there in your bytecode. so at runtime you don't need anything, no jars at all. Only a jar at compile time. That makes it 100% a real POJO. Anyone who says other, to me is just trying to be nitpicking and not correct.

Mark
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Aditya, I do want to apologize to you. I feel I was a little unfair to you. I just have a strong opinion that Annotations still keep a class POJO. Because I can run that java class without needing any jars at runtime. I can run it as if the annotations aren't even there.

But I also use both Annotations and xml, mostly Annotations though, and the big thing about the Controller, xml is still an option.

Mark
Aditya Jha
Ranch Hand

Joined: Aug 25, 2003
Posts: 227

Hi Mark,

I totally understand the passion which you feel for the technology, and I would like to believe that I share the same. This is what takes the Java community to further frontiers.

Ok. So, may be an annotated POJO is a POJO. My concern is that is this a reason good enough to warrant deprecation of a cohesive, OCP-based hierarchy of useful classes? Points 2 and 3 from my earlier post still hold water.

You see, my point is, instead of having so many classes in Collections framrwork, we may come up with something like:



instead of a TreeMap.

I understand it is unfair to compare Collections with Controllers, as Collections is more of an API (which we use directly in our code), and Controllers are part of a framework (which are often needed to be extended). However, please take the comparison in a different light. My point is, if I need a 'custom' sorted map, I have option to extend TreeMap and override what I need (and more importantly, do NOT need to implement what is already there).

Similarily, if we have the need of a 'custom' form-controller, why can't we utilize the template pattern to provide custom behaviour to an already developed, working class like SimpleFormController?


The Controllers are still there, just deprecated


For a person like me who works in an IT services company, where projects are bound by customer-provided Coding-Guidelines, its nothing less than a sin to use deprecated classes/methods. This is the very reason I'm agitated at this change. It simply closes the door for people like me to use Controllers.

Annotations are good. They are great. But, let's not have them as the ONLY option. This is all I say.

Best regards,

- Aditya Jha
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17249
    
    6

Yes, I see your point. I just wanted to let you know that they are still there, deprecated, yes, but still there, and well, I am just looking at it as a going forward approach. First, there is no longer a good reason to use AbstractFormWizardController class with Web Flow handling wizards a lot better, and easier to implement.

As to just the SimpleFormController, you had to know all the properties that you needed to set, and then set the command object. Then if you had Validators you had to implement an interface and then inject them. Then for binding you had to learn the Binding class(es) and figure them out.

Wouldn't it be nice if all those parts were handled automatically for you so you could create your web app simpler and quicker. That is what I like about using @Controller and @RequestMapping. Including using some naming conventions so that my @RequestMapping is just that, no values inside it. Also with Webflow a lot of my methods are just really POJO methods with no annotations at all. In the webflow xml file you put in your evaluation tags to call methods on events or to set up your forms.

Mark
Edward Winchester
Ranch Hand

Joined: Sep 16, 2009
Posts: 65
Aditya Jha wrote:
Annotations are good. They are great. But, let's not have them as the ONLY option. This is all I say.

Best regards,

- Aditya Jha

Aditya,

It's a year on from this thread now so I wonder what you feel about it all now?

I was using 2.5.6.SEC01 until last week when I upgraded to 3.0.0.RC3 and noticed that SimpleFormController is deprecated! I was very surprised and after a bit of searching found this thread. That's why I'm really keen to know what you feel after having time to try/ponder the annotated approach?

Thanks,

Ed
Hussein Baghdadi
clojure forum advocate
Bartender

Joined: Nov 08, 2003
Posts: 3476

I'm with the new MVC framework, it is easy as it should be.
Why the hell I have to learn a dozen of controller classes? actually I dropped older SpringMVC in the past because of this.
Joe Harry
Ranch Hand

Joined: Sep 26, 2006
Posts: 9345
    
    2

The discussions here make me give Spring MVC a try.


SCJP 1.4, SCWCD 1.4 - Hints for you, Certified Scrum Master
Did a rm -R / to find out that I lost my entire Linux installation!
 
jQuery in Action, 2nd edition
 
subject: Your opinion: Spring v3.0 deprecates Controller hierarchy
 
Similar Threads
Any decent tutorials on mocking methods
Proxy Server in Java
Connecting to Internet from my Server
Spring 3
Advantages to converting 2.x to 3?