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 Phil: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ * [jcarreira] If we agree that supporting file uploads out of the box is important, then this is just a nice feature for that support to let the user know how much of the file has been uploaded, etc. 1. Better error checking for UI tags. The freemarker error message, while great for freemarker users, look like gibberish. People should not be forced to learn freemarker. So in such cases, the tags themselves should check the parameters and report back sane messages, even if that check is duplicated in the templates - [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. + * [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. @@ -238, +238 @@ * [jcarreira] You're kidding, right? We've discussed this already.... * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [phil] -1 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [jcarreira] +1 this is biting us right now * [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 + * [phil] +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. @@ -274, +276 @@ * [jcarreira] Shouldn't annotations be the default, and XML be the override? * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see a method for representing result mappings using annotations that I actually like (due to limitations of annotations). If we can't come up with something decent, I'd just assume stick with XML; we shouldn't use annotations for the sake of using annotations. I personally don't find the xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action name to the simple name of the action class, it will be even more pleasant. I definitely think we should use annotations for things like validation. * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea. I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!) + * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
