struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Struts Wiki] Update of "RoughSpots" by Bob Lee
Date Fri, 21 Apr 2006 17:42:59 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:

The comment on the change is:
Posting comments on behalf of Hani.

      * [plightbo] As Gabe said, we already discussed this. And the last post on the subject
was that we should do it. We still should.
      * [Gabe] I've created an XWork JIRA for a solution to the same use case here. []
I'd be happy to contribute the code.
+   1. Allow paths in action names. For example `<action name="reports/myreport">`.
+   1. Enable Java package import in configuration so you don't have to repeat the same package
name over and over (like WW1 does).
+   1. The ajax support is pitiful. Have a look at how stripes does it. Ajax for validation
is trivial and not that impressive, but people are going to want to do real ajax work, and
webwork does absolutely nothing to help in that regard. I'd like to for example be able to
easily invoke actions and get at some kind of result to display, and have webwork provide
at least some of the wiring
+   1. The default theme for the ui tags should be simple. The current stuff is too dumb to
get right on the first go, which gives an awful impression. It's NOT intuitive to write: {{{
+ <table>
+ <ww:textfield label="Enter blah" />
+ </table>
+ }}}
+   1. File upload should support progress notification. Have a look at webwork-multipart
on, it's based on the pell parser but has a progress API.
+   1. Better error checking for UI tags. The freemarker error message, while great for freemarker
users, look like gibberish. People should not be forced to learn freemarker. So in such cases,
the tags themselves should check the parameters and report back sane messages, even if that
check is duplicated in the templates
+   1. Defaults should be JSP all the way. People know it and like it, despite all the limitations.
Allow for other view technologies, but don't force people to learn stuff they don't want to.
Learning ww is enough of a pain as it is
+   1. Get rid of the validation framework. it's stupid and pointless, validate methods are
good enough.
+   1. Ditch xwork as a separate project, nobody uses it or cares about it
+   1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know
+   1. Clean up documentation. Focus on quality not quantity.
  == Patrick's issues ==
  My concerns aren't as detailed as Bob's, but I would like to see these general themes promoted
by the framework:
@@ -160, +186 @@

    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).
+      * [hani] No magic method names. If you want to do that, use annotations so you have
a good chance of IDE support dealing with it. For example @Validate/@Prepare etc, with parameters
to indicate what request you'd like it involved for, in the case where you need multiples
of them
    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:
For additional commands, e-mail:

View raw message