On Apr 6, 2009, at 2:51 PM, Dan Allen wrote:
A point was raised about XML defined managed beans and where they
fit. To me, this is a backwards compatibility thing. You just have
to keep them. The quesiton becomes, do we add on to something that
is "not very powerful, but good enough for some cases" or do we try
to improve the situation? Fine, you can use @ManagedBean and that
solves a marketing problem, and good for prototypes. But it sure as
heck isn't going to fix the problem my past teams have had with
these beans having a horrible dependency injection model. That's all
I'm saying.
.
So here's what I'm concluding. I propose we keep @ManagedBean
and
@ManagedProperty to allow for quick prototyping in JSF applications
and to entice newcomers to give it a try (or upgrade). But I can
tell you that from personal experience, I will always use Seam,
Guice, Spring, or Web Beans in any production application because I
can't write an mature application with the JSF annotations alone.
But that's fine, because we have a clear migration path. If you
agree, Ed, perhaps you can communicate that to the 316 EG.
I'll grant that more complicated applications will be easier to manage
with Seam, Guice, Spring, etc, but one *can* write applications in
Plain Jane JSF, though they may be simple. But if the user just wants
to write a simple application, then that's good enough. We shouldn't
hamstring them, or guilt them into throwing more complex IoC solutions
into the mix just because We Know Better Than They. FWIW, I worked at
a shop that didn't use any of the aforementioned IoC panaceas. We
used JSF and, if necessary, EJB3. IIRC, most were simply JSF+JPA,
which fit the bill nicely. We weren't writing the next eBay, but they
kept that mid-size HVAC company, and continue to do so 3+ years after
some of them written.
Jason Lee, SCJP
Senior Java Developer, Sun Microsystems
Mojarra and Mojarra Scales Dev Team
https://mojarra.dev.java.net
https://scales.dev.java.net
http://blogs.steeplesoft.com