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 ------------------------------------------------------------------------------ * [plightbo] + 1 again. * [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. 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. @@ -89, +90 @@ * [jcarreira] We don't want to allow for extension? * [crazybob] Extension through interfaces and methods? Yes. Public/protected fields? Absolutely not! * [mrdon] I dunno, are you planning to make protected getters/setters for every field? I've found protected fields to be invaluable when extending frameworks (again, subscribing to the believe we should let the user do what they want and not artifically restrict them). I do wish you could declare the fields _only_ available to subclasses and not to the whole package. + * [crazybob] Absolutely, methods instead of fields. Methods enable us to hook access if need be, change the underlying implementation, manage thread safety, protect our own code against unexpected conditions/states, etc. Fields are OK within a package, but when it comes to public APIs, better safe than sorry a year from now. 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better. @@ -170, +172 @@ * [MJ] With JDK 1.5 as a requirement for SAF2-based projects, users may be inclined to take a look at [http://stripes.mc4j.org/confluence/display/stripes/Home Stripes] first. It is compact, it features event-dispatching, built-in validation and conversion, Action and !ActionForm being one entity, and it allows to forgo XML config files by using annotations. The last feature alone is worth sack o'gold. If SAF2 is going to require JDK 1.5, it should allow XML-free configuration, at least for simple use cases. * [plightbo] I use JDK 1.5 as well. I think we really should think about doing this. Non-1.5 options exist (WebWork 2.2 and Struts 1.3), and we're really at a close point where it is no longer unreasonable to require 1.5 (1.6 will have been out for almost 6 months by the time we hit a final release). * [mrdon] I'd like to use Java 5, but use retroweaver to continue to support 1.4. If we keep XML in addition to annotations, that should be very doable. + * [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs (concurrency for example). --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
