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 JasonCarreira: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ 1. Do we want to keep `ModelDriven`? * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. * [plightbo] I think we should give some serious thought to this. Look around the internal implementation of WebWork/XWork as well as the number of questions that come up on the mailing lists. It's a very confusing thing, especially when interacting with setting or getting values of form fields. + * [jcarreira] yes, it makes the internal implementation more complex, but it makes things easier for the user of the framework in a lot of cases. If people are confused by it, they can choose not to use it. 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? @@ -266, +267 @@ 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. * [plightbo] +1. we should keep this in mind when designing the API. + * [jcarreira] -1 to using the HttpServletRequest... Why do we need it? We've got a nice abstraction with the Maps for parameters, session, and application scopes, I think. Why tie to the servlet API and make a phony one to proxy to Portlets? 1. Add "action" and "method" attributes to the submit button tag so users don't have to know about the "action:Name" and "method:name" conventions. * [plightbo] We already do this :) @@ -296, +298 @@ * [jcarreira] I think we should have some pre-defined ones for standard things: view vs. CRUD vs. "action" -> do somthing that's not CRUD. We should then use annotations to make it where you can declaratively associate a particular action method with a "stereotype" which is mapped to an interceptor stack, etc. * [crazybob] "C[R]UD" isn't a good name because "view" == "[R]etrieve". Let's call it "update" for the moment. What will the difference be between "update" and "action"? * [plightbo] I really don't think having a "update" and "action" stack is a good idea. Let's make a single stack and then have the stack behave differently depending on the context in which the action was executed. There are several options (GET vs POST, method names, annotations, etc). + * [jcarreira] I really think this is a bad idea and will lead to great suffering... We put in interceptors to allow people to customize the processing of a request, why move away from that now? I think if we do some thinking we can think of the common use-cases that cover 80+% of the action cases, and make it very easy for an action developer to tag this action as using one of that small number of stereotypical uses. The action will then pick up the configuration set up for that stereotype (which could include things like defaulting the result pages to go to, etc.) == Gabe's Issues == 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name="view*" where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here: [https://issues.apache.org/struts/browse/WW-1133]. * [plightbo] I still don't know about this. My biggest concern is being able to do a fairly standard pattern of pushing an object on the stack (User) and then including a common snippet such as user-details.jspf. Without the stack and the ability to push, we might loose the loose coupling the value stack provides. * [Gabe] Just wanted to make it important to clarify that I am not suggesting that we remove the ability to push on the stack, just remove the push tag to do it within JSPs. Thus, in your Interceptor etc you would still be able to push. Also, allowing the ability to set on the stack is a seperate issue. It would be powerful to be able to add dynamic names to the stack rather than only be able to use static method names to an object pushed to the stack. + * [jcarreira] -1 to removing the push tag. It's very useful to push an object onto the stack and include a template to render it. +1 to making it easier to bind values to names that are easily accessible to the stack. + 1. Hope I know what I'm talking about with this one: Provide a way that request parameters can be used as a form element value in case of error. If you submit a form with a text field that requires a numeric value but you enter a non numeric value and errors are returned, you lose the value entered when the type conversion happens. * [plightbo] We support this already (the value stack has an "overrides" map which gets set when type conversion errors occur). If this isn't the case, it's simply a bug :) 1. Remove OGNL Map attributes (and List/Set to be consistent) such as size, isEmpty, iterator. These can be accessed by size(), empty, and iterator() respectively and the way it works now you can never have myMap['size'] because it will just get the size not the value of the map with key 'size'. * [plightbo] +1, all I'd ask is that we try to make it feel as much like JSTL as possible. Not sure what that means, but just something to keep in mind :) * [Gabe] I agree. OGNL is very much like JSTL already. I wonder if we can even add the few JSTL features OGNL doesn't have to OGNL and then position OGNL as an EL that "extends" JSTL. + * [jcarreira] +1 to making OGNL a superset of JSTL, unless it involves trying to be "bug-compatible". + 1. Allow indexable parameters similar to how it works in struts (with indexed="true") but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 1. Specify and simplify Interceptor scope. Currently, you have an Interceptor that calls actionInvocation.invoke() and then returns a different result than actionInvocation.invoke() returns, the actionInvocation.invoke() result will be used anyway. This is confusing and muddies the meaning of the Interceptor API, which IMHO should simply wrap the action not the action all the way through to the end of the result. The reason it's set up the way it is, as I understand it, is so that Interceptors can clean up resources like connections after the result is returned. However, I wonder if we can implement a request based object that can take care of such resources and destroy them at the end of the request rather than using Interceptors in this way. @@ -322, +329 @@ * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor` to pull an object off the session and pass it to your action. Or you can use Spring to inject session-scoped objects into your action (though I would avoid Spring personally). * [jcarreira] I can attest that the Spring scoped components work well with WebWork. It's what we use at work for maintaining session or request state. * [plightbo] Let's not dismiss Tim's comments too quickly. While we might not implement a solution exactly like he suggests, his point is valid that handling state management in WebWork has always been a very week area. The ScopeInterceptor isn't a great option either, especially considering one of my other issues specifically asks that we avoid having to create custom interceptor stacks for various actions. + * [jcarreira] I'm open to hearing good ideas for state management. Especially short-lived wizard type state. Long lived session state (things like your user profile) work really well as Spring session-scoped components, but state which is just used for the next 4 or 5 pages isn't such a good fit. 1. In tandem with the previous point, since Actions are already stateful, it'd be nice to have the ActionContext injected into the Action. One benefit is when a newbie developer needs it, the linkage is obvious (they don't have to a priori know about the ActionContext, they're being handed in it on a platter). If the developer can subclass ActionContext, it would also encourage them to implement a base action which accepts the context inject and leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser() for example, just getContext().getUser(). * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and maybe more importantly, it wouldn't automatically be available to helper classes as it is as a !ThreadLocal. That would address my concern about "inappropriate" usage of !ActionContext. @@ -371, +379 @@ } }}} If the user doesn't call a result method, we would use an intelligent default. You could implement this using an interceptor and an action support class. However, I'm with Jason: I've never needed this and I like the seperation. * [plightbo] Bob: your suggestion doesn't seem very "user friendly". I think we should really think long and hard about doing this. I'll be the first to admit that much of the reason I never thought about doing it in WebWork was purely to be "anti Struts" (sorry!). I've grown up a bit since then. The downsides I can see to this are: 1) more confusing if we offer both options, 2) views are tightly coupled to the action with no easy way to override, 3) support for both could cause problems with overriding actions, and 4) tool support, such as graphing out page flows, would be difficult or impossible for actions that use this technique. However, there are good positives for this, as already mentioned. Let's give this some real consideration. + * [jcarreira] Rather than make the framework deal with this, let's make an Action superclass or interceptor, etc which can handle this. How about an interface with one method: + + Result getResult(); + + and an interceptor which can get the result from the action (in its callback method from PreResultListener) and set this result as the one to be executed. Making this one of the stereotypes for action configuration should make it very easy to get set up. + + I think all the reasons you listed and more are the reasons we've always avoided this, and I don't think they're any less relevant today. == Nice to haves == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
