struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Struts Wiki] Trivial Update of "RoughSpots" by Bob Lee
Date Mon, 24 Apr 2006 18:18:19 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 Bob Lee:
http://wiki.apache.org/struts/RoughSpots

------------------------------------------------------------------------------
  
    1. How does WW help the user with state management?  As far as I can tell, if I want to
keep a 'user' object around I have to interact with the map returned by ActionContext.getSession().
 Actions should in general have a type-safe and transparent way to do this, e.g. by subclassing
ActionContext and providing getUser()/setUser() which store the user in session.  This allows
for re-working of the storage strategy (e.g. write a cookie and lookup the user each time)
without affecting actions.
  
-     * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor`
which pulls an object of the session and passed it to your action. Or you can use Spring.
+     * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor`
to pull an object off the session and pass it to your action. Or you can use Spring to inject
session-scoped objects into your action (though I would avoid Spring personally).
  
    1. In tandem with the previous point, since Actions are already stateful, it'd be nice
to have the ActionContext injected into the Action.  One benefit is when a newbie developer
needs it, the linkage is obvious (they don't have to a priori know about the ActionContext,
they're being handed in it on a platter). If the developer can subclass ActionContext, it
would also encourage them to implement a base action which accepts the context inject and
leveraging the fact that JDK 1.5 allows co-variant returns, also write a getContext() method
that returns the down-casted type; they wouldn't have to do ((MyActionContext) ActionContext.getContext()).getUser()
for example, just getContext().getUser().
      * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. 
If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and
maybe more importantly, it wouldn't automatically be available to helper classes as it is
as a !ThreadLocal.  That would address my concern about "inappropriate" usage of !ActionContext.
@@ -313, +313 @@

    * [martinc] The big issue with the JDK version is app servers. This comes in two parts.
First is whether all of the major app server vendors have products available that support
the desired SDK version. I believe we're OK in that regard with JDK 1.5. The bigger issue
is customer acceptance. Enterprise customers, especially, tend to standardise on their app
server, and they are not quick to upgrade. Unless the application vendor has a great deal
of influence over the customer's infrastructure, the vendor has to live with whatever app
server version is in use at the customer site. It is rare, then, that the application vendor
can dictate the JDK version. On the other hand, the customer usually couldn't care less what
version of Struts the application was built with.
    * [tfenne] I think you *have* to support JDK 1.5, and it should be the default. If it's
not too hard to provide 1.4 compatibility great, but I think all examples, defaults etc. should
leverage 1.5. Generics allow you to do much more for the user without asking for configuration
information. If a user wants to use JDK 1.5 enums, it should work, etc. etc. If it's extra
work on the user's part to make 1.5 features work, simplicity goes out the window.
    * [frankz] I think this is one of those things to be really careful about the perception
people may form.  If Action1 is going to continue to develop and be supported, even if to
a lesser degree, then forcing 1.5 for Action2 is probably fine.  However, I know at my company,
we are stuck on 1.4, and won't be changing for a long time.  I also know that we are not unique
in this regard.  If we can't move to Action2. so long as Action1 is still around and being
supported, that's fine.  But if we can't move to Action2 and it even '''seems''' like Action1
isn't getting enough attention, that wouldn't look so good to us.  Ultimately, if both can
be supported, I think that is still the best answer.  I definitely think the points made about
moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise
use Action2, so if that can be avoided, so much the better.
-   * [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 drive design decisions.
+   * [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.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org


Mime
View raw message