• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Your opinion: Spring v3.0 deprecates Controller hierarchy

 
Ranch Hand
Posts: 227
Eclipse IDE Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
ranger
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 Spring Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 17347
11
Mac IntelliJ IDE Spring
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
clojure forum advocate
Posts: 3479
Mac Objective C Clojure
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 10198
3
Mac PPC Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The discussions here make me give Spring MVC a try.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic