Sounds good Musachy.
Musachy Barroso wrote:
As far as I can see the only dependency between REST and Codebehind is
this class:
http://svn.apache.org/viewvc/struts/struts2/trunk/plugins/rest/src/main/java/org/apache/struts2/rest/ControllerClasspathPackageProvider.java?view=markup
which all it does is use Codebehind to detect actions that end in
"Controller", and optionally disable package scanning. These 2
settings could be constants declared in Codebehind and overwritten by
REST and the hard dependency would be gone(that's what I did with
Convention in order to plug REST in).
I think the problem with REST is easy to fix; one blocker down. Now,
about supporting Codebehind from Convention, any other opinions
(before pulling a vote on it)?
musachy
On Fri, May 16, 2008 at 2:30 AM, Jeromy Evans
<[EMAIL PROTECTED]> wrote:
Jeromy Evans wrote:
I wouldn't rush into this decision.
Users of the REST plugin require @Namespace, @Result, etc annotations.
Creating a duplicate set of annotations with the same purpose is not
sensible.
It's appropriate that the REST plugin has a dependency on the plugin that
auto-populates the Configuration, despite the contrary statement on the
plugins page.
Merging the REST plugin with Convention is also not possible as the
implementation of ActionInvocation and ActionMapper are entirely different
(the conventions cannot currently be mixed).
There are several issues here:
- creating a Configuration (via XML, via Annotation)
- ActionMapping (no problems here, each plugin sets up their own)
- ActionInvocation (standard or RESTful; they are incompatible)
- handling unknowns
One situation could be that Configuration is separate from Convention; so
the developer can choose how the Configuration is setup and then choose
which mapping & invocation, and unknown handling approach to use. However
that would require another refactoring.
I think making REST dependent on the Convention plugin is the way to go,
such that the Configuration is created by Convention (but customized for
REST *Controller class) and extended with the REST ActionMapper and
RestActionInvocation.
On further thought, if it is possible to split up the Convention plugin,
then it could be solved like so:
- Zero Configuration: for all annotations relating to the setup of
Configuration (merge from Convention)
- CodeBehind: implements action mapping, invocation, unknown handling, index
handling (the other half of Convention)
- REST alternative implementation of action mapping, invocation, unknown
handling
Ideally then REST can be used with ZeroConf or XMLConf, or CodeBehind used
with ZeroConf or XMLConf. Sweet.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
