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 RainerHermanns: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ lets you get the functionality of a ViewController interface without having to say "implements ViewController" in your action class. * [crazybob] +1 for keeping the `Action` interface--it enforces that `execute()` is the default method. + * [rainerh] +1 for keeping the `Action` interface and +1 for moving the result constants out. 1. Only put classes in root package that most users need to know about. For example, most don't need to know about `Default*` or `ObjectFactory`. * [plightbo] +1 on this - sounds like Bob has a good handle on what it takes to make a nice API. I'll defer to him on this. @@ -40, +41 @@ depend on versus those extending the framework should be allowed to extend. The latter category of folks can be presumed to be smaller, as well as more willing to deal with occastional API breakages. * [crazybob] +1 for "impl" package naming convention. I think we should focus on the application developer API for the initial release and then introduce a more featureful extension API in a later release. + * [rainerh] +1 for "impl" packages as well 1. Only make classes/members public if we're willing to guarantee future compatibility. Everything else should be package-private or excluded from the Javadocs. @@ -66, +68 @@ * [crazybob] It's kind of hard to forget to call `invocation.invoke()`; you have to return something. ;) Interceptors are already an "expert" feature anyway. * [plightbo] Big +1. * [mrdon] +1 as well + * [rainerh] +1 from me as well 1. Try to get rid of thread locals: `ActionContext` and `ServletActionContext`. At least make them package-private. Sometimes interceptors need access to the servlet API. In this case, they should implement a servlet-aware interceptor interface. For example: {{{ class MyInterceptor implements HttpInterceptor { @@ -100, +103 @@ 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. * [plightbo] Eh, it's not a big deal to me. Errors wouldn't be accurate either though, since there are also generic messages that you can add. + * [rainerh] What about ValidationMessages? 1. Merge `ActionContext` and `ActionProxy` into `ActionInvocation` (at least from the users' perspective). Better specify what happens during chaining/action tags. @@ -153, +157 @@ * [jcarreira] That one always has been confusing... * [mrdon] Or #requestScope keeping in line with JSTL/JSP + * [rainerh] +1 for JSTL/JSP like naming 1. Warnings and failing silently is not the best practice. For example, if we can't find a method in a given action class, blow up ASAP (at load time). We shouldn't be fuzzy and do stuff like try to find a method named `doXxx()` when we can't find a method named `xxx()` (WebWork had backward compatibility restrictions, but we don't need to perpetuate them). * [plightbo] +1, everything should be much more proactive about failing fast and failing with a nice error message. * [mrdon] Agreed, and we have done a lot of work lately on this issue. + * [rainerh] Better error reporting for developers is a very important issue. Latest additions to xwork will help here but could be improved a lot. 1. Add better support for file uploads. @@ -209, +215 @@ * [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. 1. Ditch xwork as a separate project, nobody uses it or cares about it * [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 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 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -322, +331 @@ * [crazybob] Someone made the point earlier on that if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't let 1.4 support negatively impact design decisions. * [gdinwiddie] WRT "if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too," I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). + * [rainerh] +1 for Java 5 support --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
