Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by TedHusted: http://wiki.apache.org/struts/RoughSpots The comment on the change is: Sorry for the late additions; I reviewed the page again for the release plan. ------------------------------------------------------------------------------ Some things that could be addresssed before Action 2.0.0. (If we don't address them, we'll be stuck supporting them throughout all eternity or until Struts 3.0.0, whichever comes first. ;)) + * [Ted] Action 3.0 doesn't have to be far away. It could be phase two, and ship as soon as we want to write it. + - We have a small number of existing !WebWork users compared to the number of Struts users we'll (hopefully) eventually have. This is a new framework (if only in name) and a major release. This is our one chance to break compatibility. We must get it right now, because we will *not* be able to fix most of these problems later (the cost of breaking existing Struts users will almost always outweigh the value of the fix). + We have a small number of existing !WebWork users compared to the number of Struts users we'll (hopefully) eventually have. This is a new framework (if only in name) and a major release. This is our one chance to break compatibility. We must get it right now, because we will *not* be able to fix most of these problems later (the cost of breaking existing Struts users will almost always outweigh the value of the fix). + + * [Ted] Hopefully, there will always be new major releases and new chances to break compatability. I would also hope any change we make will pay for itself by increasing future usability. Since each team will absorb the cost of their own changes, these types of costs will always scale. The relative cost for ten teams is not more than the relative cost for ten thousand teams, since each team pays their own way. Likewise, each team will receive a payback in future productivity, and so each team will receive the net gain. Of coure, there can be an economy in clustering changes, so certain changes can be made together, so sooner can be better. I doubt that there will be a stampede of people migrating the day we roll 2.0.0. My expectation would be that it would be at leaset six months or a year after the initial release of SAF2 before a majority of teams start to migrate, giving us time for additional, incremental releases. But, I am on board for whatever set of changes we can make and have ready to roll by August. We do not need to expose Struts users to XWork; they do not care. At the very least we should build a thin abstraction layer to isolate users from XWork. XWork should be an implementation detail not part of the SAF API. We can make most of the following changes in SAF's abstraction layer and avoid breaking existing XWork users. + + * [Ted] To an extent this is true. OTOH, XWork might make a very nice business facade for a lot of applications. 1. Looking up a `ResultConfig` should be a one-liner. Right now we have to: {{{ ActionConfig config = invocation.getProxy().getConfig(); @@ -263, +269 @@ 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? + * [Ted] Having lived with keys-only for all these years, I like the idea of being able to use either literals or keys. 1. Craig McC mentioned that we might want to use this in a portlet. Does this mean I should completely abstract us from `HttpServletRequest`/`PortletRequest`? * [mrdon] +1, at least in some form. This was the goal of the generic ActionContext, I believe. Cocoon has been struggling with the same issue, and they are leaning towards implementing the HttpServletRequest, et al with a portlet impl to solve this problem. They used to have this generic "Environment" api, but they are in the process of giving that up, I believe, favoring this servlet api approach. I wonder if we shouldn't find out more about their results and adopt them. @@ -437, +444 @@ <result name="input">addPerson.jsp</result> </action>}}}The ValidationInterceptor should still cause an input result to occur but if we make it through to invoking the action and there is no execute method we return the value of the configured assumed result. + * [Ted] The use case seems to be a POJO Action method. But, if the method (AddPerson) is truly POJO, then what value can it add? If it doesn't know the framework exists, then it can't utiize the runtime data. If the class does know the framework exists, why not have a helper method return SUCCESS. If there is a use case for calling a framework-aware "void" method, then if the "action" returns void, the framework could seek the default result (the one with no name) and obviate the annotation. + 1. When an action returns `LOGIN`, save the request in the session (even POSTs) and enable the user to re-execute it after login. + + == Ted's Issues === + + 1. Combine configuration DTDs so that Actions, Messages, and Validators can be defined as a single file or in a set of homogenous files. ("One config to map them all.") + + 1. Change the default for the <form> tag to "POST" (rather than "GET"). == What JDK Version? ==
