Mailing-List: contact dev-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Developers List" <dev@struts.apache.org>
Received-SPF: pass (athena.apache.org: domain of musachy@gmail.com designates
 209.85.198.232 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=OeYuk+nmEjqQafTFY1BivS1YU/7Q1vJyU6Am/8lroR1cCvNDjqUHYqahf2MoOmg5fvLhX/DxQZudJAVop/QpJnHWdIB4EJVEy6hJL8+p1YdzhKyf9earQKfZMWndriybtuc0rwjW6z5CYdGMxAyjaRr2+u0eNyDduNxgFpzAf6M=
Message-ID: <d8bdeb6f0805160621y46851315oc21c2024fdd47ba@mail.gmail.com>
Date: Fri, 16 May 2008 09:21:54 -0400
From: "Musachy Barroso" <musachy@gmail.com>
To: "Struts Developers List" <dev@struts.apache.org>
Subject: Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero
 Config
In-Reply-To: <482D29F6.7000807@blueskyminds.com.au>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <d8bdeb6f0805132039v7aac52f8gebc8877103d250c5@mail.gmail.com>
	 <436d9a250805132343sf4cc5e6s9c9be3b529b7b034@mail.gmail.com>
	 <d8bdeb6f0805151420m687720f9k5671467adf658a77@mail.gmail.com>
	 <b9e663070805151437q2f487f42t62a28a56274c1c17@mail.gmail.com>
	 <d8bdeb6f0805151648v2c16dd19m83919dd1bb1b29e1@mail.gmail.com>
	 <BLU103-DS4AB8928F46A71B49304C3D1C80@phx.gbl>
	 <d8bdeb6f0805151945t2df34577g73a86c494c6a4577@mail.gmail.com>
	 <482D27DF.2090700@blueskyminds.com.au>
	 <482D29F6.7000807@blueskyminds.com.au>

My head is spinning now :). Can you use REST with Xml Conf?

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