Right. I think I need to step back to view this from a different
perspective. You could be right, what I am trying to attempt might be a bit
'too much magic'. But a curious mind knows no limits! :-)
Thanks for input, Levi; much appreciated!
Cheers,
Rahul
levi_h wrote:
>
> Alright, then I s
Alright, then I see your point.
I don't know how many entities you would like to manage, but creating a
subclass per entity would work around it, of course (not that you hadn't
thought of that yourself). That'd be very KISS as well - I get
the impression that your current approach could be doing t
Yes, exactly! I'd like to hold a reference to Guice's TypeLiteral in such a
Context object to be able to obtain the Type(s).
Take for instance, the following method:
public Method getDefaultHandler(Class bean) throws
StripesServletException;
A couple of things with this:
1) argument 'bean' w
Could you give an example of a limitation you ran into? I've read your mail
a couple of times now and I don't understand what a context object would
add. (It could be the type parameter for the ManageEntityActionBean, but I'm
not sure.)
Another question: what functionalities would this ManageEntit
Greetings,
I want to use a custom ActionResolver implementation to be able to
handle the following scenario:
1) I have an action bean impl ManageEntityActionBean manages T
(save/view/delete), where T can be any entity - Project, ProjectGroup etc.
2) I would like to leverage Guice's TypeLiteral
