Wow... so many questions.. haha.
Q. What do you think about how convenient it will be to write unit test für
a java bean using this static method? ;-) And of course this breaks the LoD
A. The ServletContext is easy to mock up. So as long as your unit test
performs the Setup on the ServletContext you are fine. I would expect
developers to use this judiciosly and not as a common means of accessing the
injector. The static also allows me to more easily hook Guice functionality
into Stripes.
Q. Why use a Set<Injector>? are you planning to use multiple Injectors?
A. Good question. The thought did cross my mind. But, I don't have any real
use cases to support a reason for that. The actual reason for the Set had
more to do with just having a convenient way to access a statically set
variable from a non static method :) The Set works as a nice little
container.
Q. I'm wondering if somebody is extending the AnnotatedClassActionResolver.
If so, this one will be stucked. I can only think of providing 2 base
classes as solution - which seems a little bit ugly from my point of view.
A. This *is* certainly not what I would consider the way I'd prefer to do
things. But, it is the only solution available in Stripes 1.5. I implented
Stripes-Spring the same way after extensive discussion with the Stripes
devs. As a result of these and other conversations the Stripes gurus have
made concessions in Stripes 1.6. Internally this will change with Stripes
1.6 because of the new ObjectFactory. I am working to create a stripes-guice
for stripes 1.6.
Q. I really do like the constructor based injection more than the setter
based, but can it happen, that stripes autobinding overrides a property of
your actionBean? Of course we are all security freaks und we all use strict
binding but what about a less security aware programmer or some who doesn't
use final? I don't trust myself, thats why I use the Interceptor/Setter
based solution. Maybe a configuration param should enable/disable
constructor based injection.
A. I'm not sure I totally understand what you are saying. The constructor
based injection would be for properties you aren't exposing to Stripes to
override. I would expect something like a Service class not a domain object.
But, heck... you could do whatever you wanted really. I don't want to get in
the business of trying to stop folks from failing. It is way too much work
and never pays off :D
Q. What do you think about defining a Module[] factory as config param for
the Lister, so the modules compatible to your framework are not limited to
the default parameter less constructor?
A. Great idea. I'll add it to my list of planned features.
Q. How are you using the ActionBeanContext in your applications? I made the
experience that i don't need more than the build in functions when using
guice as DI framework.
A. I am not currently using this in any of my projects. After implementing
this I checked out Freddy's section on Stripes and Guice in his book and
decided to add it because it was easy to do.
Q. Are you planing to implement some logging?
A. I don't have a specific plan. But, I could add that to my list of things
to add.
Thanks for the feedback
Brandon Goodin
Silver Mind Software
http://www.silvermindsoftware.com
[email protected]
615-306-3652
http://www.linkedin.com/in/bgoodin
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
