struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: Should I announce SmartURLs or wait?
Date Tue, 18 Sep 2007 14:58:21 GMT
Okay, created the tickets.

*ConfigurationProvider loading mechanism*

    https://issues.apache.org/struts/browse/WW-2192

*Extensionless URLs*

    Don, it looks like you covered most of this. Did you add support for 
"index actions"? Smart URLs handles these like this:

URL = http://www.example.com/foo
1. First check for action named foo in namespace /
2. Send redirect to http://www.example.com/foo/

URL = http://www.example.com/foo/
1. Check for action named index in namespace /foo

This is pretty standard handling by most J2EE and HTTP containers and 
that's why I did it like that. The Smart URLs configuration provider 
sets all of this up ahead of time based on what actions it finds in the 
classpath.

*Pluggable FilterDispatcher*

    https://issues.apache.org/struts/browse/WW-2193

-bp

Don Brown wrote:
> Could you translate these ideas into JIRA tickets and mark them
> against 2.1?  After I finish with the XWork refactoring, I'd like to
> work on making the configuration providers pluggable, because as you
> said, it really opens up some interesting possibilities.  It is kinda
> tricky as you have a chicken-egg situation with providers that create
> plugins which create providers, so patches would be very welcome :)
>
> Don
>
> On 9/12/07, Brian Pontarelli <brian@pontarelli.com> wrote:
>   
>>  Well, the configuration provider is kinda a pain right now. I started a
>> thread a while back about making configuration providers pluggable via the
>> struts-plugin.xml file. I think it sorta died  because you can use init
>> parameters to setup providers in web.xml.
>>
>>  In addition, if you want to use the extensionless support as well as all
>> the index support of the plugin it requires a completely different filter,
>> but it would be much nicer to have everything just plug-in and run with as
>> little configuration as possible.
>>
>>  If we keep it a plugin then I would suggest removing zero-config from core
>> so that they don't conflict. I'd probably also want to rework the
>> DispatcherFilter to make it more pluggable so that the majority of the work
>> is from injections and then it can be changed without modifying the web.xml.
>> Lastly, the configuration providers need to be easier to setup. This would
>> probably require a more robust configuration mechanism that would pre-inject
>> configuration providers and then inject the rest of the container.
>>
>>  However, all that said, I think this should be in core. The beauty of
>> frameworks like Rails and Grails is that they give all the conventions right
>> out of the box. I feel like Struts should try to strive to match the ease of
>> these other frameworks. Otherwise, it requires the users to actually know
>> that the plugin exists, go find it, install it and then learn it all.
>>
>>  -bp
>>
>>
>>
>>  Don Brown wrote:
>>  The reason the zero config stuff is in core is mainly because it
>> requires a configuration provider, which cannot be plugged in via a
>> struts plugin. Is there any other technical reason that this should
>> be in core?
>>
>> Don
>>
>> On 9/11/07, Musachy Barroso <musachy@gmail.com> wrote:
>>
>>
>>  IMO this should be a "core" feature of struts 2.
>>
>> musachy
>>
>> On 9/10/07, Don Brown <mrdon@twdata.org> wrote:
>>
>>
>>  Hmm...along those lines, could SmartURL be Codebehind 2.0?
>>
>> As for 2.1, I'm working on a huge patch to xwork 2.1 that will, among
>> other things, make OGNL pluggable and fully migrate the code to
>> container injection (no statics!). I should be done sometime this
>> week.
>>
>> Don
>>
>> On 9/11/07, Ted Husted <husted@apache.org> wrote:
>>
>>
>>  Why wait? People using Struts 2.0.x could use it now. Struts 2.1.x
>> could be out next week, or next month, or next year. There's really no
>> telling.
>>
>> I'm not sure what "rolling it into the core" means. If it means
>> putting the source into the Struts-Core JAR, then I'd probably be
>> opposed. Personally, I'd like to keep rolling things out of the core
>> and distribute as much as possible in the form of plugins. Ultimately,
>> there should be nothing in the core that doesn't *need* to be in the
>> core. My thought would be to include SmartURLs in Struts 2.1.x as the
>> successor to the CodeBehind plugin.
>>
>> -Ted.
>>
>> On 9/10/07, Musachy Barroso <musachy@gmail.com> wrote:
>>
>>
>>  +1 for waiting and rolling it into core, it could be available for 2.1
>>
>> musachy
>>
>> On 9/10/07, Brian Pontarelli <brian@pontarelli.com> wrote:
>>
>>
>>  I was planning on release 1.0 of SmartURLs in the near future and doing
>> some announcements to the user lists and some other locations. However,
>> should I wait on that if favor of rolling this back into core, or should
>> I go ahead?
>>
>> Thoughts?
>>
>> -bp
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>>
>>
>>
>>     
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>   


Mime
View raw message