struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dusty <dustin_pea...@yahoo.com>
Subject Re: [VOTE] Bring Convention plugin into trunk and deprecate Zero Config
Date Sat, 31 May 2008 15:53:49 GMT

It is an interesting situation.  I think its clear that majority of mind
share an momentum on the configuration side is with the Convention plugin.  
REST is hot and so people are going to want to try an use the REST plugin
for action invocation.   Ideally, we would want the best of both worlds in a
single package to minimize user confusion.  

Don's point is a valid one, but I also hope that he agrees that its a good
thing to somehow combine REST and Convention.  I am not so sure that
changing how Struts fundamentally works so that we can include more and
competing plugins at runtime is a good thing.  It is that type of confusion
that makes the framework hard for the masses to absorb.

I think combining the REST and Convention as a new super config plugin. 
Keeping the REST plugin separate but dependant on other plugins seems wrong
anyhow.  The idea of a legacy jar to support existing plugins works I think. 
Forking REST is not so great but having two complete offerings is better
than several incomplete ones.  You could even take a look at the Restlet +
XWork bridge posted earlier as the REST stack on top of Convention if you
wanted.  Although my initial thought on that work was "cool, but not quite
struts-native enough".

I just feel like we have been stuck on this issue for a while and with
current trends in web frameworks, REST and Convention over Configuration are
the two hottest topics these days.  Struts should try and present a clear
and strong solution as soon as possible and then spread that message.




Musachy Barroso wrote:
> 
> The only conflict between codebehind and convention is on the
> UnknownHandler. If struts would support multiple UnknownHandler(s),
> like it supports multiple PackageProvider(s), we wouldn't have a
> problem at all, and they could be able to co-exist without knowing
> anything about each other. Given a request and multiple
> UnknownHandler, the first one that could return an action config would
> be used.
> 
> musachy
> 
> On Fri, May 30, 2008 at 9:39 PM, Don Brown <mrdon@twdata.org> wrote:
>> On Thu, May 29, 2008 at 7:21 AM, dusty <dustin_pearce@yahoo.com> wrote:
>>> So lets do it and consolidate all of the configuration automation into
>>> Convention.  We can get the new Convention and REST in 2.1.3-SNAPSHOT
>>> and
>>> then update the Codebehind page that its being absorbed into Convention.
>>>
>>> I say the new version of Convention doesn't have to support Codebehind
>>> if
>>> its going to hold back the Convention code base.
>>
>> I disagree, because if we just "switched" the rest plugin to use the
>> Convention plugin, we'd be screwing existing apps that use either the
>> Codebehind or REST plugin, of which I personally know several.  At the
>> very least, the Conventions plugin should support Codebehind
>> applications via a separate conventions-legacy.jar project.  We need
>> to be much better about not making backwards-incompatible changes for
>> our users, as one could argue that was Struts 1's greatest strength
>> and secret to much of its success.
>>
>> Don
>>
>> ---------------------------------------------------------------------
>> 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
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-VOTE--Bring-Convention-plugin-into-trunk-and-deprecate-Zero-Config-tp17222798p17576647.html
Sent from the Struts - Dev mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message