Welcome Tim Fennell from Stripes! (was Update of "RoughSpots" by TimFennell)

[Don Brown <mr...@twdata.org>]

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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>   



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