Well, it might be the wrong way in the long run,
but for now it is a viable approach for an application.
I do not think that there should be just one way to
fetch a bean (which would be IoC)
Face it getting a managed bean is rough for a newby, with all the faces context
variable resolver stuff.
Having some kind of factory where you simply can fetch a managed bean once you
need it is a
viable approach.
But going IoC only easily can become a maintenance nightmare as well, lets keep
things open and do not lock users into one pure approach.
I also like IoC and the elegance in which Seam does this is really convincing,
but I would never tell users to use IoC only because in my opinion each approach
has its merits and downsides.
IoC in xml config files can become a huge nightmare once you have more than a
handful
of interwoven beans.
But it is awesome if you have to deal with Mockup objects which you then have
to replace on the
fly with real implementations or AOP.
So finding a good middle way probably is the way to go for now ;-)
I do not thing that going IoC only is a really good approach as long
as you have to keep the entire data in xml graves, once you can apply this stuff
via annotations like Seam does it, it might be the best way to go (if you do not
get locked out of central config files)
But in the end this is a philosophical discussion and nothing more ;-), and
everone
should use whatever is best to achieve the results ;-)
Simon Kitching wrote:
> Werner Punz wrote:
>
>> QueryHelper qh = new QueryHelper(); ---> HERE I'm making a new Object
>> of the second bean!!! The methods of the object qh fill some
>> SelectItem[] Variables...
>>
>> this is your problem, you should use the jsf variable resolver mechanism
>> to take care of the backend bean generation.
>>
>> I can recommend to use the excellent JsfUtil class you can find
>> on www.javaworld.com and in appfuse, which encapsules all the
>> mechanisms. This class has a getManagedBean method which takes care
>> of all that.
>
>
> I think the "getManagedBean" method is looking at the problem the wrong
> way. The server world is definitely moving towards "dependency
> injection" as a replacement for "dependency lookup". Examples are
> Spring, HiveMind, EJB3.
>
> JSF supports "dependency injection" in the managed bean declarations:
>
>
> <managed-bean>
> <managed-bean-name>queryHelper</managed-bean-name>
> <managed-bean-class>example.QueryHelper</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> </managed-bean>
>
> <managed-bean>
> <managed-bean-name>foo</managed-bean-name>
> <managed-bean-class>example.Foo</managed-bean-class>
> <managed-bean-scope>session</managed-bean-scope>
> <!-- use dependency injection to pass queryHelper -->
> <managed-property>
> <property-name>queryHelper</property-name>
> <value>#{queryHelper}</value>
> </managed-property>
> </managed-bean>
>
> This will cause Foo.setQueryHelper(obj) to be called when a "managed
> bean" instance of Foo is created, passing the queryHelper managed bean
> instance as a parameter.
>
> No need to "look up" the bean at all; it gets effectively passed as an
> "initialisation value" to the Foo object.
>
>
> NB: the lookup implemented by the JsfUtils lib will work, and there's
> nothing wrong with it. It just seems a little "old fashioned" now.
>
> NB2: Someone did report difficulties getting this approach working with
> JSF on Spring.
>
> Regards,
>
> Simon
>
