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]
