struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Struts Wiki] Update of "RoughSpots" by CraigMcClanahan
Date Mon, 24 Apr 2006 00:36:01 GMT
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:

      * [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
+       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 "" for
public APIs, and
+       "" 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
    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
      * [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
+     * [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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message