Not really, but so far some people think we should support it on others think it is a bad idea.
musachy On Fri, May 16, 2008 at 2:01 PM, Martin Cooper <[EMAIL PROTECTED]> wrote: > On Fri, May 16, 2008 at 10:50 AM, Musachy Barroso <[EMAIL PROTECTED]> 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)? > > > Why a vote? Is this so contentious that you don't believe we can reach > consensus? > > -- > Martin Cooper > > >> >> 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] >> > >> > >> >> >> >> -- >> "Hey you! Would you help me to carry the stone?" Pink Floyd >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > -- "Hey you! Would you help me to carry the stone?" Pink Floyd --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
