Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Your opinion: Spring v3.0 deprecates Controller hierarchy

 
Aditya Jha
Ranch Hand
Posts: 227
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Aditya Jha
Ranch Hand
Posts: 227
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 227
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 227
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3479
Clojure Mac Objective C
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 10124
3
Eclipse IDE Mac PPC Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The discussions here make me give Spring MVC a try.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic