David Evans wrote:
I was looking in DefaultActionMapper and am wondering about the
compatibilityMode switch functionality. In getMapping compatibilityMode
is used to see whether to check for the ! method idiom. I assume this is
because it will eventually be removed because wildcard mappings make it
redundant. But in the constructor, the PrefixTrie that's being set up is
also checking the compatibilityMode switch to see if it should add a
node for the "method:" prefix. Should that be there? Is there someway in
which you can use wildcards in your mapping in order to replace the
parameter prefix? So that the button the user clicks will determine
which method is run?
The problem we are addressing is the ability to explicitly specify the method to
be invoked from the URL. Instead, users should use wildcards where this
functionality is necessary. To replace the method: prefix, you would instead
use "action:foo!input", then use a wildcard in your "foo" action name to support
the method call. In this way, the developer has to specifically allow this,
rather than the framework keeping that door (hole?) open.
Don
dave
But, if no one is interested in working on the new API now, it should
not be framed as an impediment to a stable Struts 2.0 release. We
should judge each distribution on terms of what we have done, not on
what we would like to do.
-Ted.
On 7/24/06, Hubert Rabago <[EMAIL PROTECTED]> wrote:
On 7/24/06, Ted Husted <[EMAIL PROTECTED]> wrote:
-1 on changing the versioning scheme.
But, I would be open to something like
* Struts 2.0 == "WebWork transtional release"
* Struts 2.1 == "new API release"
* Struts 3.x == "phase 2 - the best of breed release"
...with pointers on what to consider if users should upgrade or not,
and a clear explanation of what to expect in the near future. This
could address Tim's initial concern (which I think is valid):
"Users who don't keep completely up to date with the latest goings on will see
this as the latest and greatest and start migrating to it, only to
have a very rude surprise when large changes occur in 2.1, or a 3.0
arrives months later."
Those three lines above, listing 2.0, 2.1 and 3.x, could be
communicated on the front page, on a simple table. This would be
similar to how Tomcat explains why they have three versions. Very
straightforward and easy to digest.
Hubert
IMHO, all the users, including ourselves, are served best when we
release early and release often.
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
