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] Update of "RoughSpots" by Bob Lee
Date Wed, 19 Apr 2006 00:46:00 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 Bob Lee:
http://wiki.apache.org/struts/RoughSpots

------------------------------------------------------------------------------
  
    1. `TextProvider` is a bad 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... (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)
+   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... 
+     * 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.
  

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


Mime
View raw message