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 Bob Lee
Date Wed, 19 Apr 2006 21:43:16 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. Use a lot more conventions with easy overrides.
    1. Don't dismiss XML entirely - annotations are nice but currently can't be HotSwapped
(due to a bug in the JDK). For any configuration, we should read in the following order: XML,
annotations, convention.
-      * [jcarreira] Shouldn't annotations be the default, and XML be the override?
+     * [jcarreira] Shouldn't annotations be the default, and XML be the override?
+     * [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.
    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.

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


Mime
View raw message