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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
