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 JasonCarreira
Date Fri, 21 Apr 2006 19:55:41 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 JasonCarreira:
http://wiki.apache.org/struts/RoughSpots

------------------------------------------------------------------------------
      * [Gabe] I've created an XWork JIRA for a solution to the same use case here. [http://jira.opensymphony.com/browse/XW-387]
I'd be happy to contribute the code.
  
    1. Allow paths in action names. For example `<action name="reports/myreport">`.
+     * [jcarreira] Why do you want this? Isn't this part of the namespace of the action?
  
    1. Enable Java package import in configuration so you don't have to repeat the same package
name over and over (like WW1 does).
+     * [jcarreira] +1 if it can be made sane... It can get confusing. It also makes tool
support worse (i.e. IDEA can find it as a fully qualified class name)
  
    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
+     * [jcarreira] Well, that's a relatively simple usecase, and I think it IS supported...
at least we use it at work?
  
    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>
  }}}
+     * [jcarreira] That depends on whether you're using the form tag or not, but agreed...
the XHTML theme should be cleaned up and made the default.
  
    1. File upload should support progress notification. Have a look at webwork-multipart
on java.net, it's based on the pell parser but has a progress API.
+     * [jcarreira] We've implemented this at work with WebWork fileupload + DWR + a class
that looks at the file as it's uploading to see how big it is on disk
  
    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.
+     * [jcarreira] -1 I take offense at this... It's neither stupid NOR pointless, and we
use it extensively. It's the best validation framework I've seen out there, and NO, validate
methods are NOT enough. For instance, we define reusable validations for our domain models
and use them for both the web front end as well as web services and batch imports. 
  
    1. Ditch xwork as a separate project, nobody uses it or cares about it
+     * [jcarreira] You're kidding, right? We've discussed this already.... 
  
    1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know
of).
+     * [jcarreira] +1 this is biting us right now
  
    1. Clean up documentation. Focus on quality not quantity.
+     * [jcarreira] Didn't you read the book? ;-)
  
  == Patrick's issues ==
  
@@ -187, +196 @@

       * [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
+     * [jcarreira] I think RoR has shown that convention over configuration is liked by lots
of people... these should be straightforward to figure out without annotations.
+ 
    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