You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2007/10/07 14:08:55 UTC
[s2] Goal - no experimental code in core for 2.1
With the latest refactorings in XWork that allow plugins to provide
code that load Packages, I'd like to suggest that we make it a key
design feature of Struts 2.1 that Core includes no code labeled
"experimental".
Here is what I imagine it would entail:
1. Move the zero conf code (annotations and code from
ClasspathConfigurationProvider) into the codebehind plugin.
2. Move restful mapper into its own plugin
There are two main general advantages of this from a user perspective:
1. Code from core can be fully trusted to be deemed of GA quality
2. Using zero conf and restful features become easier
While the first one is pretty self-explanatory, the second makes sense
when you think about how plugins work. Currently, to use the zero
conf or restful code, you have to have the right jars, config
settings, and follow poorly documented rules. If, for example, the
restful code was its own plugin, you could drop the restful jar in and
it would configure your application with the appropriate settings
automatically - disable .action extension, enable slashes in action
names, set the restful mapper, etc. Right now, it takes some voodoo
magic to get restful and zero conf working right (especially
together), even for me and I wrote most of it :(
By moving the zero conf code into the codebehind plugin, we also make
it easier to maintain, document, and use for developers. Also, it
makes it easier for other plugins, like SmartURL, to provide an
alternate zero conf implementation.
A different, but related discussion, is how best to provide zero conf
in Struts 2, and honestly, I don't see a clear solution yet. What is
in core now is ok, SmartURL improves things, but other parts I don't
like as much, so by putting them all on the same playing field, I'd
hope we encourage innovation.
Anyways, back to the main topic, I'd like to get all experimental code
out of core. Any objections?
Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Ian Roughley <ia...@fdar.com>.
+1 - Having to explain the exception or the configuration voodoo is
always difficult.
Don Brown wrote:
> With the latest refactorings in XWork that allow plugins to provide
> code that load Packages, I'd like to suggest that we make it a key
> design feature of Struts 2.1 that Core includes no code labeled
> "experimental".
>
> Here is what I imagine it would entail:
>
> 1. Move the zero conf code (annotations and code from
> ClasspathConfigurationProvider) into the codebehind plugin.
>
> 2. Move restful mapper into its own plugin
>
> There are two main general advantages of this from a user perspective:
> 1. Code from core can be fully trusted to be deemed of GA quality
> 2. Using zero conf and restful features become easier
>
> While the first one is pretty self-explanatory, the second makes sense
> when you think about how plugins work. Currently, to use the zero
> conf or restful code, you have to have the right jars, config
> settings, and follow poorly documented rules. If, for example, the
> restful code was its own plugin, you could drop the restful jar in and
> it would configure your application with the appropriate settings
> automatically - disable .action extension, enable slashes in action
> names, set the restful mapper, etc. Right now, it takes some voodoo
> magic to get restful and zero conf working right (especially
> together), even for me and I wrote most of it :(
>
> By moving the zero conf code into the codebehind plugin, we also make
> it easier to maintain, document, and use for developers. Also, it
> makes it easier for other plugins, like SmartURL, to provide an
> alternate zero conf implementation.
>
> A different, but related discussion, is how best to provide zero conf
> in Struts 2, and honestly, I don't see a clear solution yet. What is
> in core now is ok, SmartURL improves things, but other parts I don't
> like as much, so by putting them all on the same playing field, I'd
> hope we encourage innovation.
>
> Anyways, back to the main topic, I'd like to get all experimental code
> out of core. Any objections?
>
> Don
>
> ---------------------------------------------------------------------
> 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
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Tom Schneider <sc...@gmail.com>.
+1 for anything that makes configuration easier
Don Brown wrote:
> With the latest refactorings in XWork that allow plugins to provide
> code that load Packages, I'd like to suggest that we make it a key
> design feature of Struts 2.1 that Core includes no code labeled
> "experimental".
>
> Here is what I imagine it would entail:
>
> 1. Move the zero conf code (annotations and code from
> ClasspathConfigurationProvider) into the codebehind plugin.
>
> 2. Move restful mapper into its own plugin
>
> There are two main general advantages of this from a user perspective:
> 1. Code from core can be fully trusted to be deemed of GA quality
> 2. Using zero conf and restful features become easier
>
> While the first one is pretty self-explanatory, the second makes sense
> when you think about how plugins work. Currently, to use the zero
> conf or restful code, you have to have the right jars, config
> settings, and follow poorly documented rules. If, for example, the
> restful code was its own plugin, you could drop the restful jar in and
> it would configure your application with the appropriate settings
> automatically - disable .action extension, enable slashes in action
> names, set the restful mapper, etc. Right now, it takes some voodoo
> magic to get restful and zero conf working right (especially
> together), even for me and I wrote most of it :(
>
> By moving the zero conf code into the codebehind plugin, we also make
> it easier to maintain, document, and use for developers. Also, it
> makes it easier for other plugins, like SmartURL, to provide an
> alternate zero conf implementation.
>
> A different, but related discussion, is how best to provide zero conf
> in Struts 2, and honestly, I don't see a clear solution yet. What is
> in core now is ok, SmartURL improves things, but other parts I don't
> like as much, so by putting them all on the same playing field, I'd
> hope we encourage innovation.
>
> Anyways, back to the main topic, I'd like to get all experimental code
> out of core. Any objections?
>
> Don
>
> ---------------------------------------------------------------------
> 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
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Piero Sartini <li...@pierosartini.de>.
Am Montag, 8. Oktober 2007 21:06:10 schrieb Brian Pontarelli:
> Oh, forgot one thing. I like the idea of a single codebehind/zero-conf
> plugin that is beta. So, I'm voting that we collapse SU and the code
> from struts2 core and the current codebehind plugin into a single
> location. This would move all the experimental stuff out of core and
> still allow users to start using all the current features as we work on
> the others that Ted and others have mentioned (including myself).
+1 for something that can be used by the users (me) easily. I already used SU
for a small project and it is just great. But I do not like the situation
with struts 2.1 (mainly because SU doesn't work with xwork 2.1). I would try
to fix it, but if you merge everything maybe this is useless work.
Everything is confusing - codebehind/zero-conf is the "old" plugin, isn't it?
Is it better to use SU or codebehind/zero-conf? Choice is good, plugin-hell
is not.
If you ask me, I would answer that it is best to let SU replace the
codebehind/zero-conf thing in s2 (as an official plugin, maybe tagged beta).
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Ted Husted <hu...@apache.org>.
We still consider the zero-config and codebehind code in Struts 2.0 to
be experimental. Going forward, we do not want to leave that code in
the core, because we want to stabilize the core.
We were always very clear that the zero-config and codebehind features
were experimental and subject to change. I don't believe we need to
"deprecate" any of this, since they were never labeled a supported
feature.
For Struts 2.1, Don's proposal is that we move all of the zero-config
code into the codebehind plugin, and merge into that code from
SmartURLs plugin, so that there is no "experimental" code in the core.
The codebehind plugin for 2.1 would adopt the SmartURLs conventions
and annotations.
1 - For 2.1, move zero-config code into codebehind plugin
2 - Merge SmartURLs conventions and annotations into the 2.1 codebehind plugin
3 - Leave the 2.0 SmartURLs plugin at GoogleCode
>From 2.1 onward, we would consider the new codebehind conventions to
be stable, and, if we want to change the conventions thereafter, then
we would take more drastic steps, which could even include bringing
out a different plugin under a different name. But, I don't think we
need to do that yet.
Personally, I would suggest that this is an ideal time to thoroughly
exercise and document the new conventions and encourage everyone
upgrading from 2.0 to 2.1 to adopt those conventions, and leave the
"experimental" conventions behind.
Though, I would also like to continue work on the SmartURLs plugin for
2.0, so that we can use that as the basis for testing and documenting
the conventions now, until the 2.1 refactoring is complete.
-Ted.
On 10/10/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> Initially I figured we could pull things from zero-conf, code-behind and
> SmartURLs out into the plugin and then work from there. But now I'm
> thinking that deprecating all the old code-behind, zero-conf and
> SmartURLs stuff were it is at and not supporting it any longer might be
> best. Most of this stuff is working as is and allowing folks to use
> those features from the current locations shouldn't impact new
> development going forward. Therefore, leaving it where it is at should
> be fine and then starting a new plugin called convention or something
> based on the Struts and SmartURLs code bases in a brand new package.
>
> OR we could do this:
>
> 1. Pull out the existing SmartURLs, zero-conf and codebehind into a new
> plugin called convention or something.
> 2. Deprecate all of it but ensure it works seamlessly.
> 3. Create new annotations, classes, etc in a new package
> (org.apache.struts2.plugin.convention) based off the existing code.
> 4. Update things as needed to get it all working with no mods or
> application breakage.
> 5. Plan removal dates for the old code. I'd say 2.2 would be fine.
>
> Thoughts?
>
> -bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Brian Pontarelli <br...@pontarelli.com>.
Initially I figured we could pull things from zero-conf, code-behind and
SmartURLs out into the plugin and then work from there. But now I'm
thinking that deprecating all the old code-behind, zero-conf and
SmartURLs stuff were it is at and not supporting it any longer might be
best. Most of this stuff is working as is and allowing folks to use
those features from the current locations shouldn't impact new
development going forward. Therefore, leaving it where it is at should
be fine and then starting a new plugin called convention or something
based on the Struts and SmartURLs code bases in a brand new package.
OR we could do this:
1. Pull out the existing SmartURLs, zero-conf and codebehind into a new
plugin called convention or something.
2. Deprecate all of it but ensure it works seamlessly.
3. Create new annotations, classes, etc in a new package
(org.apache.struts2.plugin.convention) based off the existing code.
4. Update things as needed to get it all working with no mods or
application breakage.
5. Plan removal dates for the old code. I'd say 2.2 would be fine.
Thoughts?
-bp
Ted Husted wrote:
> If we want stable conventions, then we should try to exercise the
> conventions against more applications, to be sure we're covering the
> core use cases. I know some of us are trying these with our own
> applications, but we should also try them with more example
> applications that we can all review.
>
> In-house, we have MailReader and Showcase. I've a preliminary
> implementation of the MailReader up that works (at least in a single
> namespace). Perhaps we should move the work-in-progress from
> GoogleCode to the sandbox, or even to SmartURLs as its 2.0.x example.
>
> Another likely candidate would be a "Petstore Zero". I have a Petstore
> site started on Google Code, if anyone would like to join in. A JPA
> implementation might be especially helpful.
>
> If we had these three applications working well, with no XML actions,
> bare minimum annotations, and sensible validation, then there would be
> a good chance that we would be covering enough of the basis to keep
> the conventions stable moving forward.
>
> Moving forward, I'm willing to consider the conventions a core
> feature, even if we ship them as a plugin. Meaning that if we do want
> to break backwardly compatibility to introduce a different set of
> standard conventions, I'd vote to roll the major version number, for
> that reason alone.
>
> Of course, before we get to the point of rolling a version number, we
> would have had been able to try the conventions in the form of an
> alternate plugin for some time. As mentioned, distributing features in
> a plugin format makes it much easier to throughly test new things
> ourselves, before we make changes to the standard distribution.
>
> (And encore kudos to Don for bringing us the plugin feature and
> initial codebehind plugin that have made all this possible!)
>
> -Ted.
>
> On 10/8/07, Don Brown <mr...@twdata.org> wrote:
>
>> On 10/9/07, Ted Husted <hu...@apache.org> wrote:
>>
>>> So, in the same way that WebWork 2 became Struts 2, SmartURLs 2.1 will
>>> become CodeBehind 2.1.
>>>
>> I'm fine with this on one condition: 100% backwards compatibility.
>> Backwards compatibility is so crucial for convention-based designs,
>> because there is no clear feedback to the user that changes have been
>> made.
>>
>> If you change an API, you probably deprecate the old methods, which
>> gives immediate feedback to the user that something has changed, and
>> they can usually view the javadocs on the deprecated method to see the
>> suggested fix. If you just remove a method, the compiler will
>> immediately tell the user something has changed. With a
>> convention-based system, things just stop working and the user has no
>> immediate reason why or how to fix it.
>>
>> This is one reason I like the idea of moving the zero conf out to a
>> plugin is it is easier to develop new convention-based systems, while
>> allowing legacy apps to continue working using the older system.
>>
>> Don
>>
>
> ---------------------------------------------------------------------
> 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
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Ted Husted <hu...@apache.org>.
If we want stable conventions, then we should try to exercise the
conventions against more applications, to be sure we're covering the
core use cases. I know some of us are trying these with our own
applications, but we should also try them with more example
applications that we can all review.
In-house, we have MailReader and Showcase. I've a preliminary
implementation of the MailReader up that works (at least in a single
namespace). Perhaps we should move the work-in-progress from
GoogleCode to the sandbox, or even to SmartURLs as its 2.0.x example.
Another likely candidate would be a "Petstore Zero". I have a Petstore
site started on Google Code, if anyone would like to join in. A JPA
implementation might be especially helpful.
If we had these three applications working well, with no XML actions,
bare minimum annotations, and sensible validation, then there would be
a good chance that we would be covering enough of the basis to keep
the conventions stable moving forward.
Moving forward, I'm willing to consider the conventions a core
feature, even if we ship them as a plugin. Meaning that if we do want
to break backwardly compatibility to introduce a different set of
standard conventions, I'd vote to roll the major version number, for
that reason alone.
Of course, before we get to the point of rolling a version number, we
would have had been able to try the conventions in the form of an
alternate plugin for some time. As mentioned, distributing features in
a plugin format makes it much easier to throughly test new things
ourselves, before we make changes to the standard distribution.
(And encore kudos to Don for bringing us the plugin feature and
initial codebehind plugin that have made all this possible!)
-Ted.
On 10/8/07, Don Brown <mr...@twdata.org> wrote:
> On 10/9/07, Ted Husted <hu...@apache.org> wrote:
> > So, in the same way that WebWork 2 became Struts 2, SmartURLs 2.1 will
> > become CodeBehind 2.1.
>
> I'm fine with this on one condition: 100% backwards compatibility.
> Backwards compatibility is so crucial for convention-based designs,
> because there is no clear feedback to the user that changes have been
> made.
>
> If you change an API, you probably deprecate the old methods, which
> gives immediate feedback to the user that something has changed, and
> they can usually view the javadocs on the deprecated method to see the
> suggested fix. If you just remove a method, the compiler will
> immediately tell the user something has changed. With a
> convention-based system, things just stop working and the user has no
> immediate reason why or how to fix it.
>
> This is one reason I like the idea of moving the zero conf out to a
> plugin is it is easier to develop new convention-based systems, while
> allowing legacy apps to continue working using the older system.
>
> Don
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Don Brown <mr...@twdata.org>.
On 10/9/07, Ted Husted <hu...@apache.org> wrote:
> So, in the same way that WebWork 2 became Struts 2, SmartURLs 2.1 will
> become CodeBehind 2.1.
I'm fine with this on one condition: 100% backwards compatibility.
Backwards compatibility is so crucial for convention-based designs,
because there is no clear feedback to the user that changes have been
made.
If you change an API, you probably deprecate the old methods, which
gives immediate feedback to the user that something has changed, and
they can usually view the javadocs on the deprecated method to see the
suggested fix. If you just remove a method, the compiler will
immediately tell the user something has changed. With a
convention-based system, things just stop working and the user has no
immediate reason why or how to fix it.
This is one reason I like the idea of moving the zero conf out to a
plugin is it is easier to develop new convention-based systems, while
allowing legacy apps to continue working using the older system.
Don
>
> -Ted.
>
> ---------------------------------------------------------------------
> 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
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Ted Husted <hu...@apache.org>.
On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> Oh, forgot one thing. I like the idea of a single codebehind/zero-conf
> plugin that is beta. So, I'm voting that we collapse SU and the code from
> struts2 core and the current codebehind plugin into a single location. This
> would move all the experimental stuff out of core and still allow users to
> start using all the current features as we work on the others that Ted and
> others have mentioned (including myself).
The key question is what to do about 2.0.x. It would be cool if 2.1.x
went GA right away, but that never seems to happen :(
My suggestion would be to go ahead and try and make SmartURLs
feature-complete for 2.0.x as a GoogleCode plugin, and also merge it
into 2.1.x as the new CodeBehind plugin (while extracting the Zero
Configuration features into the CodeBehind plugin).
This way, we retain the status quo for 2.0.x in terms of the existing
SmartURLs and CodeBehind plugins. For 2.1.x, there would just be the
one CodeBehind plugin, which would also include the Zero Configuration
features now embedded in the Struts 2.0.x core.
So, in the same way that WebWork 2 became Struts 2, SmartURLs 2.1 will
become CodeBehind 2.1.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Brian Pontarelli <br...@pontarelli.com>.
Oh, forgot one thing. I like the idea of a single codebehind/zero-conf
plugin that is beta. So, I'm voting that we collapse SU and the code
from struts2 core and the current codebehind plugin into a single
location. This would move all the experimental stuff out of core and
still allow users to start using all the current features as we work on
the others that Ted and others have mentioned (including myself).
-bp
Ted Husted wrote:
> I like where SmartURLs is going, but, as it stands, I'd still call it
> incomplete and experimental. For an approach like SmartURLs (or
> ZeroConfiguration/CodeBehind) to be truly useful, we should be able to
> at least write something like the MailReader with a bare number of
> ActionName annotations (ideally, 0). I'd also like to try a
> zero-config ShowCase application.
>
> I'm trying to find time to review the source code and come up with
> some patches. I think if the current list of issues were resolved, I
> think it would be a great idea to merge SmartURLs with the new
> ZeroConfig/CodeBehind plugin.
>
> Here's a summary list of the missing features I came across trying to
> implement MailReader:
>
> SU-5 Support ReST-style parameters
> * hello-world/save?message=Howdy == hello-world/save/message/Howdy
>
> SU-6 Extend result-type search scope
> * /foo/bar/hello-error.jsp, /foo/bar/error.jsp, /error.jsp, and then
> fall back to /foo/bar/hello.jsp
>
> SU-7 Automatically chain action (if any) when branching to other pages
> * If Foo.execute returns "bar", we check for FooBar.class
>
> SU-16 Heuristic alias matching
> * for hello-input, (1) HelloInput.execute, (2) Hello.input
>
> I'd also like to review the validation annotations tickets, since
> there were some glitches there too (especially with Skip). (Has anyone
> compared the XWork validation annotations with the Hibernate
> annotations? Are we compatible?)
>
> -Ted.
>
> On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> So, should I go ahead and start promoting SmartURLs or should we
>> continue to attempt to collapse the zero-conf/codebehind stuff into
>> SmartURLs?
>>
>> -bp
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Ted Husted <hu...@apache.org>.
On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:
> I think it would also be useful to take a swing at having message bundles
> that don't require classes (as it sounds like is the current case - although
> I haven't looked into it). I don't think empty classes should be required at
> all.
One work-around would be to specify actions/package.properties as the
struts.custom.i18n.resources.
For now, I'll go ahead and do that and scuttle the empty MRZ classes,
so that we can be closer to the ideal.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Brian Pontarelli <br...@pontarelli.com>.
I think it would also be useful to take a swing at having message
bundles that don't require classes (as it sounds like is the current
case - although I haven't looked into it). I don't think empty classes
should be required at all.
Also, one of my other troubles with things is that handling most CRUD
operations requires a lot of duplication or a single class with two
actions, the insert and update, so that validation and relational id
handling (either single or multiple) are consistent. I think there is a
way to fix this, just need to think about it for a while and brain-storm
on the lists.
-bp
Ted Husted wrote:
> I like where SmartURLs is going, but, as it stands, I'd still call it
> incomplete and experimental. For an approach like SmartURLs (or
> ZeroConfiguration/CodeBehind) to be truly useful, we should be able to
> at least write something like the MailReader with a bare number of
> ActionName annotations (ideally, 0). I'd also like to try a
> zero-config ShowCase application.
>
> I'm trying to find time to review the source code and come up with
> some patches. I think if the current list of issues were resolved, I
> think it would be a great idea to merge SmartURLs with the new
> ZeroConfig/CodeBehind plugin.
>
> Here's a summary list of the missing features I came across trying to
> implement MailReader:
>
> SU-5 Support ReST-style parameters
> * hello-world/save?message=Howdy == hello-world/save/message/Howdy
>
> SU-6 Extend result-type search scope
> * /foo/bar/hello-error.jsp, /foo/bar/error.jsp, /error.jsp, and then
> fall back to /foo/bar/hello.jsp
>
> SU-7 Automatically chain action (if any) when branching to other pages
> * If Foo.execute returns "bar", we check for FooBar.class
>
> SU-16 Heuristic alias matching
> * for hello-input, (1) HelloInput.execute, (2) Hello.input
>
> I'd also like to review the validation annotations tickets, since
> there were some glitches there too (especially with Skip). (Has anyone
> compared the XWork validation annotations with the Hibernate
> annotations? Are we compatible?)
>
> -Ted.
>
> On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
>> So, should I go ahead and start promoting SmartURLs or should we
>> continue to attempt to collapse the zero-conf/codebehind stuff into
>> SmartURLs?
>>
>> -bp
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Ted Husted <hu...@apache.org>.
I like where SmartURLs is going, but, as it stands, I'd still call it
incomplete and experimental. For an approach like SmartURLs (or
ZeroConfiguration/CodeBehind) to be truly useful, we should be able to
at least write something like the MailReader with a bare number of
ActionName annotations (ideally, 0). I'd also like to try a
zero-config ShowCase application.
I'm trying to find time to review the source code and come up with
some patches. I think if the current list of issues were resolved, I
think it would be a great idea to merge SmartURLs with the new
ZeroConfig/CodeBehind plugin.
Here's a summary list of the missing features I came across trying to
implement MailReader:
SU-5 Support ReST-style parameters
* hello-world/save?message=Howdy == hello-world/save/message/Howdy
SU-6 Extend result-type search scope
* /foo/bar/hello-error.jsp, /foo/bar/error.jsp, /error.jsp, and then
fall back to /foo/bar/hello.jsp
SU-7 Automatically chain action (if any) when branching to other pages
* If Foo.execute returns "bar", we check for FooBar.class
SU-16 Heuristic alias matching
* for hello-input, (1) HelloInput.execute, (2) Hello.input
I'd also like to review the validation annotations tickets, since
there were some glitches there too (especially with Skip). (Has anyone
compared the XWork validation annotations with the Hibernate
annotations? Are we compatible?)
-Ted.
On 10/8/07, Brian Pontarelli <br...@pontarelli.com> wrote:
>
> So, should I go ahead and start promoting SmartURLs or should we
> continue to attempt to collapse the zero-conf/codebehind stuff into
> SmartURLs?
>
> -bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: [s2] Goal - no experimental code in core for 2.1
Posted by Brian Pontarelli <br...@pontarelli.com>.
So, should I go ahead and start promoting SmartURLs or should we
continue to attempt to collapse the zero-conf/codebehind stuff into
SmartURLs?
-bp
Don Brown wrote:
> With the latest refactorings in XWork that allow plugins to provide
> code that load Packages, I'd like to suggest that we make it a key
> design feature of Struts 2.1 that Core includes no code labeled
> "experimental".
>
> Here is what I imagine it would entail:
>
> 1. Move the zero conf code (annotations and code from
> ClasspathConfigurationProvider) into the codebehind plugin.
>
> 2. Move restful mapper into its own plugin
>
> There are two main general advantages of this from a user perspective:
> 1. Code from core can be fully trusted to be deemed of GA quality
> 2. Using zero conf and restful features become easier
>
> While the first one is pretty self-explanatory, the second makes sense
> when you think about how plugins work. Currently, to use the zero
> conf or restful code, you have to have the right jars, config
> settings, and follow poorly documented rules. If, for example, the
> restful code was its own plugin, you could drop the restful jar in and
> it would configure your application with the appropriate settings
> automatically - disable .action extension, enable slashes in action
> names, set the restful mapper, etc. Right now, it takes some voodoo
> magic to get restful and zero conf working right (especially
> together), even for me and I wrote most of it :(
>
> By moving the zero conf code into the codebehind plugin, we also make
> it easier to maintain, document, and use for developers. Also, it
> makes it easier for other plugins, like SmartURL, to provide an
> alternate zero conf implementation.
>
> A different, but related discussion, is how best to provide zero conf
> in Struts 2, and honestly, I don't see a clear solution yet. What is
> in core now is ok, SmartURL improves things, but other parts I don't
> like as much, so by putting them all on the same playing field, I'd
> hope we encourage innovation.
>
> Anyways, back to the main topic, I'd like to get all experimental code
> out of core. Any objections?
>
> Don
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>