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 CraigMcClanahan: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ * [plightbo] Related to this, I would encourage us to try to find a solution (using Bob's mix-in suggestion below, or possibly just taking advantage of the value stack) that would make ActionSupport much simpler. This would encourage using POJOs more. * [mrdon] Regardless whether we remove Action or not, I like the idea of moving the result constants out. * [tfenne] I think removing Action would be a bad idea. If you're going to try and get away from requiring XML configuration or listing out all your Actions somewhere, you'll probably want to have someway of discovering your Actions. An interface is the easiest option - an annotation would do too, but would feel a little stranger I think. + * [craigmcc] You can actually have this one both ways, as we do in Shale -- define an Action interface for + the JDK 1.4 users, and provide an optional JavaSE 5 layer that lets you define the appropriate callbacks + with annotations instead. For a detailed example, take a look at how Shale's "Tiger Extensions" package + lets you get the functionality of a ViewController interface without having to say "implements + ViewController" in your action class. 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. * [mrdon] +1 + * [craigmcc] In Shale, I adopted the convention of package "org.apache.shale.foo" for public APIs, and + "org.apache.shale.foo.impl" for things like default implemetnation classes. However, there is an additional + subtlety here to take into account -- there is a difference between APIs that application developers should + 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. 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. @@ -35, +45 @@ * [mrdon] This I don't agree with. From a framework developer, I understand the logic, but from a user, it is arrogant. I think we should allow people to extend Struts in ways we haven't imagined, and restricting access like this says, "We know more than you and will force you to do it our way." * [crazybob] I don't think we should make everything final or anything, but I do think we should differentiate between the published API and the implementation through package organization, excluding stuff from the Javadocs, etc. Users can know that we won't change the published API out from under them, but that if they depend on implementation classes, we may break them (reluctantly). It's the polite thing to do, and it frees us up to refactor and improve our implementation. * [jcarreira] +1 published public vs. private APIs are a good thing, and a contract with the user of what can change. + * [craigmcc] See comments on the previous bullet related to APIs that application developers use versus those + who are extending the framework might use. 1. Remove `destroy()` and `init()` from `Interceptor`. They don't make much sense until the interceptor lifecycle is specified (see next item). I've never needed them, yet it's a pain to implement empty methods every time I implement an interceptor. Users can use the constructor/finalizer or we can create additional lifecycle interfaces. @@ -68, +80 @@ * [mrdon] This I'd like to see. I've found myself using these objects so often in wierd little places, I'd be loath to remove them unless we could prove 100% that their information can be retrieved elsewhere. * [jcarreira] +1 to Patrick's point... we may need to introduce some more advanced *Aware interfaces, though, to give people access to the guts if they really want it. * [frankz] !ActionContext being !ThreadLocal was one of the first "cool" things I noticed about WW. I'd hate to see that change. The only thing I can think of that would make me agree to change that is that I think we may find developers using it in "inappropriate" ways, i.e., an Action calls a business delegate and the delegate uses !ActionContext. My bet is most people would agree it should be a "best practice" to not do that. Still, it's cool that you can! + * [craigmcc] JSF likes the thread local approach to a per-request context object (FacesContext in this case) + too. One of the really nice benefits is simplifying parameter signatures to methods that *might* need + access to the context state, but not necessarily. The counter-example, of course, is the Struts signature + for Action.perform(). Two more comments separated out because they address separate issues. + * [craigmcc] Regarding Frank's concern about potential "inappropriate" changes ... if you design an API that + passes a particular interface in to a method, and then expects that method to pass the same interface along, + you are in exactly the same boat. The Servlet API considers this a feature rather than a bug, because a + Filter can actually wrap the incoming request and response objects to provide extra functionality -- this + at least wouldn't be possible in the case of a thread-local state object. + * [craigmcc] "Interceptors need access to the servlet API" -- doesn't anyone care about making it possible + to write applications that work for portlets too? I would hope that we all work towards a world where + direct access to the underlying servlet API objects is considered an anti-pattern. 1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
