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 plightbo: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ [phil] This is, depending on what you want, fairly easy to really complicated. You can easily register a new FreemarkerExceptionHandler in components.template.FreemarkerTemplateEngine to limit the stacktraces. But it will still be gibberish if you don't know what happens (eg. " Error on line 43, column 13 in template/simple/select.ftl - stack.findString(parameters.listValue) is undefined. It cannot be assigned to itemValue]" -> that hardly tells you you specified a non-existant method for listValue in your select box). Solution: we should do more checking in the components instead before rendering. 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is - [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. + * [plightbo] Agreed - examples, default results, etc should be JSP. However, we need to keep UI tags in a template language so they can be used in all view technologies. Right now that is FreeMarker, though if we can find a template language that is more like JSP (say, without the scripplets), I would like to switch to that. 1. Get rid of the validation framework. it's stupid and pointless, validate methods are good enough. * [jcarreira] -1 I take offense at this... It's neither stupid NOR pointless, and we use it extensively. It's the best validation framework I've seen out there, and NO, validate methods are NOT enough. For instance, we define reusable validations for our domain models and use them for both the web front end as well as web services and batch imports. * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at least), sometimes for simple validation it is nice to be able to just describe it (using xml or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write custom validator is really cool. Please reconsider this. :-) * [frankz] -1 as well. If you had said the validation framework could stand to be enhanced and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless or stupid at all. Declarative validation is a fantastic approach, especially with validator being a separate Commons component. For instance, we are working on a project at work that is going to use Validator and the CoR implementation in JWP as the basis for a rules engine... I put together a proof of concept showing how we could use the exact same validations in the web front-end via AJAX calls as in the Web Service interface for other systems to call on. Being able to write those validations in XML without having to write actual code was a great thing. * [crazybob] I think sharing validations between AJAX and Java more than justifies the framework. I would like to see us replace most if not all of the XML with annotations. - * [rainerh] -1 on removing the valdation framework. This is one of the best, if not the best validation framework I've seen so far. + * [rainerh] -1 on removing the validation framework. This is one of the best, if not the best validation framework I've seen so far. 1. Ditch xwork as a separate project, nobody uses it or cares about it * [jcarreira] You're kidding, right? We've discussed this already.... @@ -243, +244 @@ * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there more to it? * [rainerh] +1 as well * [tm_jee] +1 + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) + * [plightbo] The reference docs are great, but we failed terribly on the tutorials and non-reference docs. 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. 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? 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. 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 :) == Patrick's issues == @@ -282, +288 @@ * [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). == 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] + 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. 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 :) 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. @@ -302, +312 @@ 1. How does WW help the user with state management? As far as I can tell, if I want to keep a 'user' object around I have to interact with the map returned by ActionContext.getSession(). Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing ActionContext and providing getUser()/setUser() which store the user in session. This allows for re-working of the storage strategy (e.g. write a cookie and lookup the user each time) without affecting actions. * [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. 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. * [jcarreira] I think this is a bad idea, in general. Actions should specify the exact things they need and have them supplied, not just ask for the "world" (the ActionContext is the world the action lives in). * [mrdon] While I agree more specific is generally better, I like the idea of the user being able to subclass ActionContext for their particular application. Tapestry has the Visit object (I think that's the name) I've always liked. + * [plightbo] Tim's suggestion of allowing actions to get the ActionContext without referencing the thread local is a good one. This is in line with other requests to reduce the number of situations where users have to deal with ThreadLocals. 1. HTML analog tags should stick to HTML attributes. I don't mean they shouldn't have more functionality, but the attributes should be identical where possible, and they shouldn't do things like render a label and an input. Keeping them more like regular HTML tags makes them easier to ramp up on, and more non-developer friendly * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit scoped variables like "actionName", "actionAddress", etc. to create dynamic values; this looks pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use non-HTML-looking tags + more abstract attributes + "media" attribute, thus creating something like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one. @@ -349, +361 @@ } } }}} 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. == Nice to haves == --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
