Re: [Springframework-developer] Another BeanFactory feature

[Ivan R. <iv...@we...>]

> I've just prototyped another potential BeanFactory feature that tackles the
> PicoContainer head on.
> 
> I call it "autowire". Another new optional attribute on <bean>, although it
> could be supported in non-XML factories as well.
 >
 > ...
 >
> Is this worthwhile behaviour? Should I commit it (probably tomorrow)?
> 
> Again I think the marketing value is the most important thing. This would
> enable us to say that we can do anything PicoContainer does, and more.
> 
> Whether I'd use it myself, I'm not sure. But it wouldn't bother me if I
> didn't choose to use it.

   I am giving my comments from a position of someone who has only
   observed Spring from a (sometimes short) distance but hasn't used
   in a project yet. Please feel free to disregard my comments if you
   wish.

   When I was trying out the Web MVC part of Spring I got confused
   with the behavior of the SpringServlet (hope I got the name right),
   where I didn't have to give it anything - it simply went to
   the application context and got stuff out of it itself.
   Things were happening somehow and it wasn't clear how. It took
   me some time to figure out what was happening. Honestly, that
   part of the framework is still a bit blurry to me.

   On a similar note, I would prefer to have only one way to
   configure beans. I understand how it may look interesting to
   have beans wired automatically but I suspect people will then have
   to put comments to explain to other people what's really going on.

   In a way, wiring the beans manually is a form of documentation
   how system works. So, if it were up to me I would cancel all
   automagical processes. Besides, we will probably soon have GUI
   tools to configure our beans with and that will be more fun
   anyway.

-- 
ModSecurity (http://www.modsecurity.org)
[ Open source IDS for Web applications ]