Re: [Springframework-developer] Another BeanFactory feature

[Colin S. <col...@ex...>]

Ivan Ristic wrote:

>
>> 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.
>
I think automagic behaviour is actually quite good when it covers almost all
cases actually. Typing a lot of the same stuff over and over is no good when
a framework can do it for you in 99% of the cases. I would really hate to
have to on a regular basis do work that a framework can do for me, just to
make things clearer on initial use.

On the basis of the above though, I certainly don't think the new stuff 
Rod is
describing qualifies for being on by default, since it wouldn't apply 
much of
the time. But I do think it's maybe worth being in there are an option, 
if even
for the marketing aspect. Like it or not, people have a number of choices in
what frameworks/containers they use; we think Spring is the best choice, but
sometimes people will not get past a pure feature comparison, so sometimes
you have to add some things just on this basis.

Regards,
Colin