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 The comment on the change is: Posting comments on behalf of Hani. ------------------------------------------------------------------------------ * [plightbo] As Gabe said, we already discussed this. And the last post on the subject was that we should do it. We still should. * [Gabe] I've created an XWork JIRA for a solution to the same use case here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute the code. + 1. Allow paths in action names. For example `<action name="reports/myreport">`. + + 1. Enable Java package import in configuration so you don't have to repeat the same package name over and over (like WW1 does). + + 1. The ajax support is pitiful. Have a look at how stripes does it. Ajax for validation is trivial and not that impressive, but people are going to want to do real ajax work, and webwork does absolutely nothing to help in that regard. I'd like to for example be able to easily invoke actions and get at some kind of result to display, and have webwork provide at least some of the wiring + + 1. The default theme for the ui tags should be simple. The current stuff is too dumb to get right on the first go, which gives an awful impression. It's NOT intuitive to write: {{{ + <table> + <ww:textfield label="Enter blah" /> + </table> + }}} + + 1. File upload should support progress notification. Have a look at webwork-multipart on java.net, it's based on the pell parser but has a progress API. + + 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 + + 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 + + 1. Get rid of the validation framework. it's stupid and pointless, validate methods are good enough. + + 1. Ditch xwork as a separate project, nobody uses it or cares about it + + 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). + + 1. Clean up documentation. Focus on quality not quantity. + == Patrick's issues == My concerns aren't as detailed as Bob's, but I would like to see these general themes promoted by the framework: @@ -160, +186 @@ 1. Address the confusing issue of the validation/workflow lifecycle and different methods (this is mentioned in more detail above, but it is something that is problematic). Right now we sort of hack it by making the "input" method a special case in webwork-default.xml. * [jcarreira] +1 : Carlos at G**gle had some good ideas for this... basically stuff like if your action method is foo() then you'd have prepareFoo() and validateFoo(), but then I added that the prepare() and validate() methods should be the defaults that we call for all action methods. * [crazybob] Interesting idea. Might be overkill (i.e. at that point, the user should probably create another action class). + * [hani] No magic method names. If you want to do that, use annotations so you have a good chance of IDE support dealing with it. For example @Validate/@Prepare etc, with parameters to indicate what request you'd like it involved for, in the case where you need multiples of them 1. Don't encourage lots of interceptor stacks. Ideally the normal user should never need to deal with them. It is better to have a larger stack that has optional features that could be turned on through annotations or marker interfaces than to encourage users to build their own stacks. * [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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
