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] Update of "RoughSpots" by GabrielZimmerman
Date Thu, 20 Apr 2006 17:01:09 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 GabrielZimmerman:
http://wiki.apache.org/struts/RoughSpots

------------------------------------------------------------------------------
      * [crazybob] I think that's what he means. Speaking of annotations, I've yet to see
a method for representing result mappings using annotations that I actually like (due to limitations
of annotations). If we can't come up with something decent, I'd just assume stick with XML;
we shouldn't use annotations for the sake of using annotations. I personally don't find the
xwork.xml as annoying as XML in other places. If we do simple things like defaulting the action
name to the simple name of the action class, it will be even more pleasant. I definitely think
we should use annotations for things like validation.
  
    1. Fail fast with detailed error messages, ideally ones that show you what you did wrong
and what you should to.
+      * [Gabe] +1 I've created an XWork issue related: [http://jira.opensymphony.com/browse/XW-388]
    1. Address the confusing issue of the validation/workflow lifecycle and different methods
(this is mentioned in more detail above, but it is something that is problematic). Right now
we sort of hack it by making the "input" method a special case in webwork-default.xml.
       * [jcarreira] +1 : Carlos at G**gle had some good ideas for this... basically stuff
like if your action method is foo() then you'd have prepareFoo() and validateFoo(), but then
I added that the prepare() and validate() methods should be the defaults that we call for
all action methods.
       * [crazybob] Interesting idea. Might be overkill (i.e. at that point, the user should
probably create another action class).
    1. Don't encourage lots of interceptor stacks. Ideally the normal user should never need
to deal with them. It is better to have a larger stack that has optional features that could
be turned on through annotations or marker interfaces than to encourage users to build their
own stacks.
  
       * [jcarreira] I think we should have some pre-defined ones for standard things: view
vs. CRUD vs. "action" -> do somthing that's not CRUD. We should then use annotations to
make it where you can declaratively associate a particular action method with a "stereotype"
which is mapped to an interceptor stack, etc.
+ 
+ == Gabe's Issues ==
+   1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action
names something like name="view*" where the wildcard can then be used elsewhere as a variable.
Another idea is allowing one action configuration to extend another or having default action
configuration that other action configurations can use.
+   1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can
get rid of using the context for user app variables and reserve it for framework variables.
The user then wouldn't need to know anything about the context, just the stack. Also, this
allows us to get rid of the '#' sign completely in expressions. Similarly remove the push
tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and
here: [https://issues.apache.org/struts/browse/WW-1133]
+   1. Hope I know what I'm talking about with this one: Provide a way that request parameters
can be used as a form element value in case of error. If you submit a form with a text field
that requires a numeric value but you enter a non numeric value and errors are returned, you
lose the value entered when the type conversion happens. 
+   1. Remove OGNL Map attributes (and List/Set to be consistent) such as size, isEmpty, iterator.
These can be accessed by size(), empty, and iterator() respectively and the way it works now
you can never have myMap['size'] because it will just get the size not the value of the map
with key 'size'.
+   1. Allow indexable parameters similar to how it works in struts (with indexed="true")
but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189].
This is unfortunately not trivial at all. 
+   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.
+ 
+ 
  == 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): {{{
@@ -187, +198 @@

    * [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).
+   * [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.
  

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


Mime
View raw message