Redesign of core first two lifecycle stages ActionResolvement and
HandlerResolution
-----------------------------------------------------------------------------------
Key: STS-331
URL: http://mc4j.org/jira/browse/STS-331
Project: Stripes
Issue Type: Task
Affects Versions: Release 1.4.2
Reporter: Sebastian Wiemer
Assigned To: Tim Fennell
I noticed, that the basic interface ActionBeanResolver is very tightly coupled
to the default implementation requirements of AnnotatedClassActionResolver and
NameBasedActionResolver. It introduces many methods not necessarily required by
other implementations like getDefaultHandler() or getUrlBindingFromPath().
In my opinion stripes would be easier to customize if those core interfaces
would be more general like
interface ActionResolver {
ActionBean getActionBean( ActionBeanContext context );
}
and separating HandlerResolution completly from the ActionResolver
implementation
interface HandlerResolver {
Method getHandler( Class<? extends ActionBean> ab, ActionBeanContext context
);
String getEventName( Class<? extends ActionBean> ab, ActionBeanContext
context );
// well, maybe something like the following would be better as of performance
issues at
// booth information could be retrieved on one method call and provides
several points
// for future extensions ;)
class ActionHandler {
String name;
Method method;
}
ActionHandler getHandler( Class<? extends ActionBean ab, ActionBeanContext
context );
}
With the same ability to configure the implementation in the Stripes-Filter
like with ActionResolver (providing a default implementation indeed)
Having a closer look into DispatcherServlet and the corresponding
DispatcherHelper this should would not really be a hard job to do as of the
clean Lifecycle-stage design and separation.
Another design issue which breaks the concept of easy overwriting default
behaviour is the the fact, that the singleton ActionClassCache is used
in several places like eg DefaultActionBeanPropertyBinder. At the moment
DefaultActionBeanPropertyBinder fails, if the ActionClassCache has not been
initalized correctly which is implemented in AnnotatedClassActionResolver.
But ActionClass caching is not always reasonable like eg 'Scripted Actions'
which are dynamically reloaded ;)
A possible solution would be to centralise cache access through the
applications configuration instance.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://mc4j.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Stripes-development mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-development
