struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Struts Wiki] Trivial Update of "RoughSpots" by TedHusted
Date Wed, 19 Apr 2006 01:12:04 GMT
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


Mime
View raw message