For those who may not recognize Tim, he is the author of the rising
Stripes [1] framework that aims to simplify action-based web development
building entirely on Java 5. As the Struts Action 2 discussion moves
towards Java 5, we've asked him to join the discussion and bring his
lessons learned from Stripes to help guide our design. To be clear,
Stripes is not "merging" with Struts, but rather our two projects will
hopefully begin to better collaborate and share ideas. As of the
recently released 1.3, Stripes is now licensed under the Apache license,
which should help facilitate information and code sharing.
I'd also like to extend the offer of collaboration to any other web
framework out there. I believe Struts and WebWork have taken an
unprecedented move by merging, and hope this spirit of cooperation will
continue to spread.
Welcome Tim!
Don
[1] http://stripes.mc4j.org/confluence/display/stripes/Home
Apache Wiki wrote:
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 TimFennell:
http://wiki.apache.org/struts/RoughSpots
The comment on the change is:
Added some my issues, and commented on existing ones.
------------------------------------------------------------------------------
* [crazybob] I'll buy that. We do need to move the constants out and
encourage users to use static import (Effective Java Item 17).
* [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.
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.
@@ -213, +214 @@
1. Get rid of the use of static constant variables that are used in the key
in the stack and accessed all over the place like
XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the
OgnlContextState class, but it's not complete and I'm not sure if that's the
best way to do it.
+ == Tim's Issues ==
+ I'm new around here, so be nice ;) I probably have a lot less WW experience
than most, so I apologize in advance if I'm flat out wrong about some of the
things here.
+
+ 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.
+ 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().
+ 1. HTML analog tags should stick to HTML attributes. I dont' mean they
shouldn't have more functionality, but the attributes should be identical where
possible, and they shouldn't do things like render a label and an input.
Keeping them more like regular HTML tags makes them easier to ramp up on, and
more non-developer friendly
+ 1. Actions should return concrete objects, not symbolic results. Symbolic results
might have been optimal when you had one event/method per action and the outcomes were
always whole-page views, but they get in the way now. When you want to return anything
that requires more than the symbol, you have to do some less than intuitive things to
make the Action and the Result cooperate. I'd prefer to see a concrete Result get
returned from Action methods, which would allows developers to do more powerful things
more easily. There are a bunch of ways to make it backward compatible too. You could
return 'new SymbolicResult("success")' and have the SymbolicResult do the
lookup stuff (You could even redefine the String constants to be SymbolicResults). You
could alternatively use a static class to do Results.find(SUCCESS). Or you could even
allow method to continue to return String or Result, and if String wrap it in a
SymbolicResult.
+
+
== Nice to haves ==
1. Inheritance is not a good way to reuse code between actions. One work around is to use the strategy pattern to swap in different implementations of interfaces like `ValidationAware`. It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For example, instead of extending a class that implements `ValidationAware`, SAF could extend an action class at runtime and implement the `ValidationAware` methods by delegating them to another object (a mixin): {{{
@@ -255, +265 @@
* [crazybob] Sounds good. We'll also need to handle JDK-1.5 only APIs
(concurrency for example).
* [Gabe] I am required to use 1.4 at work. To me the question of whether to
require 1.5 comes down to whether the same shops that are stuck using 1.4 are
also not going to let people use Struts 2.0, because it is too bleeding edge
anyway. In that case it doesn't make sense to allow 1.4, because the only
people who would be using it would also have access to 1.5 anyway. I don't know
if that is the case though.
* [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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
