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 too much eventually
(though I've been wrong before). [An additional thought is that you could
create these subclasses on the fly, using a bytecode library.]
I'm afraid I don't see another easy option at the moment, but maybe someone
else does.
Regards,
Levi
On Sat, Nov 1, 2008 at 10:52 PM, rahul.thakur.xdev <
[EMAIL PROTECTED]> wrote:
>
>
> 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<? extends ActionBean> bean) throws
> StripesServletException;
>
> A couple of things with this:
> 1) argument 'bean' will not provide any Type(s) info
> 2) I have some custom Annotations on ManageEntityActionBean that allow for
> customization of handlers for each type of entity, so I need to get that
> info to be able to obtain appropriate handlers.
>
> To answer your other question:
> No, for the scope of this ActionBean, I have no other functionality except
> for CRUD operations.
>
> Cheers,
> Rahul
>
>
>
> levi_h wrote:
> >
> > 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 ManageEntityActionBean
> > offer? CRUD screens (à la Rails' scaffolds)? And would you have custom
> > functionality for certain entities, or not?
> >
> > Regards,
> > Levi
> >
> > On Sat, Nov 1, 2008 at 9:47 AM, Rahul Thakur
> > <[EMAIL PROTECTED]>wrote:
> >
> >> 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<T> manages T
> >> (save/view/delete), where T can be any entity - Project, ProjectGroup
> >> etc.
> >> 2) I would like to leverage Guice's TypeLiteral to hold the
> >> parameterized type info an runtime to be able to instantiate appropriate
> >> ActionBean instances - ManageEntityActionBean<Project> and
> >> ManageEntityActionBean<ProjectGroup> etc.
> >> 3) Resolve paths to appropriate ActionBean instances in (2) above. Say,
> >> /manageProject.action to be handled by a ManageEntityActionBean<Project>
> >> instance, so on and so forth.
> >>
> >> So I started off a custom ActionResolver implementation, but I quickly
> >> ran into limitations with the ActionResolver API. I think what I am
> >> missing is some sort of ActionResolutionContext (an arbitraty term!) to
> >> be exposed via the ActionResolver API, and then the custom
> >> ActionResolver implementation can do fancy things with it. In this above
> >> case, the ActionResolutionContext can hold the hints required to resolve
> >> to appropriate implementation.
> >>
> >> What do you guys reckon?
> >>
> >> Look forward to thoughts...
> >>
> >> Thanks,
> >>
> >> Rahul
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Stripes-users mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/stripes-users
> >>
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> > challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> > world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Stripes-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/stripes-users
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Custom-ActionResolver-implementation-pains-tp20278590p20284747.html
> Sent from the stripes-users mailing list archive at Nabble.com.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Stripes-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/stripes-users
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
