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
>
>
|