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 ------------------------------------------------------------------------------ * [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">`. + * [jcarreira] Why do you want this? Isn't this part of the namespace of the action? 1. Enable Java package import in configuration so you don't have to repeat the same package name over and over (like WW1 does). + * [jcarreira] +1 if it can be made sane... It can get confusing. It also makes tool support worse (i.e. IDEA can find it as a fully qualified class name) 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 + * [jcarreira] Well, that's a relatively simple usecase, and I think it IS supported... at least we use it at work? 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> }}} + * [jcarreira] That depends on whether you're using the form tag or not, but agreed... the XHTML theme should be cleaned up and made the default. 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. + * [jcarreira] We've implemented this at work with WebWork fileupload + DWR + a class that looks at the file as it's uploading to see how big it is on disk 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. + * [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. 1. Ditch xwork as a separate project, nobody uses it or cares about it + * [jcarreira] You're kidding, right? We've discussed this already.... 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 1. Clean up documentation. Focus on quality not quantity. + * [jcarreira] Didn't you read the book? ;-) == Patrick's issues == @@ -187, +196 @@ * [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 + * [jcarreira] I think RoR has shown that convention over configuration is liked by lots of people... these should be straightforward to figure out without annotations. + 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]
