struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Blake Byrnes" <blakebyr...@gmail.com>
Subject Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
Date Fri, 16 May 2008 17:58:58 GMT
I think it also depends on the unknown mapping handler in Codebehind.  The
class takes care of determining the jsp to use when nothing is specified in
the configurations.

<bean type="com.opensymphony.xwork2.UnknownHandler"
class="org.apache.struts2.codebehind.CodebehindUnknownHandler" />


On Fri, May 16, 2008 at 1:50 PM, Musachy Barroso <musachy@gmail.com> 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
> <jeromy.evans@blueskyminds.com.au> 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: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message