[Struts Wiki] Trivial Update of "RoughSpots" by TedHusted

[Apache Wiki <wi...@apache.org>]

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:
Conform pronouns to use "we" throughout

------------------------------------------------------------------------------
+ Some things that could be addresssed before Action 2.0.0.
+ 
-   1. Looking up a `ResultConfig` should be a one-liner. Right now you have to: {{{
+   1. Looking up a `ResultConfig` should be a one-liner. Right now we have to: {{{
  ActionConfig config = invocation.getProxy().getConfig();
  Map results = config.getResults();
  ResultConfig resultConfig;
@@ -17, +19 @@

    
    1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much sense until the interceptor lifecycle is specified (see next item). I've never needed them, yet it's a pain to implement empty methods every time I implement an interceptor. Users can use the constructor/finalizer or we can create additional lifecycle interfaces.
  
-   1. Specify `Interceptor` lifecycle. Right now if you apply an interceptor to a single action, you get a new instance every time. If you define an interceptor in a stack, the same instance gets reused.
+   1. Specify `Interceptor` lifecycle. Right now if we apply an interceptor to a single action, we get a new instance every time. If we define an interceptor in a stack, the same instance gets reused.
  
-   1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. You can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (you see `AroundInterceptor` over and over).
+   1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. We can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (we see `AroundInterceptor` over and over).
  
    1. Try to get rid of thread locals: `ActionContext` and `ServletActionContext`. At least make them package-private. Sometimes interceptors need access to the servlet API. In this case, they should implement a servlet-aware interceptor interface. For example: {{{
  class MyInterceptor implements HttpInterceptor {
@@ -34, +36 @@

  
    1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at least from the users' perspective). Better specify what happens during chaining/action tags.
  
-   1. I'm not sure I'd expect `ActionInvocation.getResult()` to recurse over chain results. Maybe we should have two methods? `getResult()` and `getFinalResult()`. I've never needed this so I don't know.
+   1. Should `ActionInvocation.getResult()` recurse over chain results? Maybe we should have two methods? `getResult()` and `getFinalResult()`. Is there a good use case for this?
  
    1. `ActionInvocation.invokeActionOnly()`. Does this need to be public? Sounds dangerous.
  
@@ -42, +44 @@

  
    1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better.
  
-   1. `TextProvider` is a bad name. The JDK refers to these as "messages" everywhere.
+   1. Is `TextProvider` a good name? The JDK refers to these as "messages" everywhere.
  
-   1. Come up with a clean way to separate "view" actions from "update" actions. For example, you may have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. You don't want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method. My current project has separate interceptor stacks, but it would be nice if there was some first class support for this. We could flag action invocations as "view" or "update" (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... 
+   1. Come up with a clean way to separate "view" actions from "update" actions. For example, we might have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. Do we want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method? One solution is separate interceptor stacks, but it would be nice if there were some first class support for this. We could flag action invocations as "view" or "update" (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... 
      * MJ: Using GET for render and POST for submit works well unless you want to trigger event with a link. Also, these links might help: DataEntryForm, EventActionDispatcher
      * crazybob: Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: "GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval."
  
-   1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. I think we should rename these `#request` for request parameters and `#requestAttributes` for request attributes.
+   1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers to the parameters. We could rename these `#request` for request parameters and `#requestAttributes` for request attributes.
  
-   1. Warnings and failing siltently sucks. For example, if we can't find a method in a given action class, blow up ASAP (at load time). We shouldn't be fuzzy and do stuff like try to find a method named `doXxx()` when we can't find a method named `xxx()` (WebWork had backward compatibility restrictions, but we don't need to perpetuate them).
+   1. Warnings and failing silently is not the best practice. For example, if we can't find a method in a given action class, blow up ASAP (at load time). We shouldn't be fuzzy and do stuff like try to find a method named `doXxx()` when we can't find a method named `xxx()` (WebWork had backward compatibility restrictions, but we don't need to perpetuate them).
  
    1. Add better support for file uploads.
  
@@ -60, +62 @@

  
  == Nice to haves ==
  
-   1. Inheritance is a sucky way to reuse code between actions. I've actually had to use the strategy pattern to swap in different implementations of stuff like `ValidationAware`. It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For example, instead of me extending a class that implements `ValidationAware`, Struts can extend my action class at runtime and implement the `ValidationAware` methods by delegating them to another object (a mixin): {{{
+   1. Inheritance is not a good way to reuse code between actions. One work around is to use the strategy pattern to swap in different implementations of interfaces like `ValidationAware`. It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For example, instead of extending a class that implements `ValidationAware`, SAF could extend an action class at runtime and implement the `ValidationAware` methods by delegating them to another object (a mixin): {{{
  abstract class MyAction implements Validateable, ValidationAware {
  
    public void validate() {
      addActionError(...);
    }
  } 
- }}} You could specify mixin implementation classes by convention (defaults), in the `struts.xml`, or using annotations. This could also be a simpler alternative to action chaining in many cases. 
+ }}} We could specify mixin implementation classes by convention (defaults), in the configuration file, or using annotations. This could also be a simpler alternative to action chaining in many cases. 
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org