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 Mon, 24 Apr 2006 18:12:12 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

------------------------------------------------------------------------------
        with annotations instead.  For a detailed example, take a look at how Shale's "Tiger
Extensions" package
        lets you get the functionality of a ViewController interface without having to say
"implements
        ViewController" in your action class.
+     * [crazybob] +1 for keeping the `Action` interface--it enforces that `execute()` is
the default method.
  
    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.
@@ -38, +39 @@

        subtlety here to take into account -- there is a difference between APIs that application
developers should
        depend on versus those extending the framework should be allowed to extend.  The latter
category of folks
        can be presumed to be smaller, as well as more willing to deal with occastional API
breakages.
+     * [crazybob] +1 for "impl" package naming convention. I think we should focus on the
application developer API for the initial release and then introduce a more featureful extension
API in a later release.
  
    1. Only make classes/members public if we're willing to guarantee future compatibility.
Everything else should be package-private or excluded from the Javadocs.
    
@@ -89, +91 @@

        you are in exactly the same boat.  The Servlet API considers this a feature rather
than a bug, because a
        Filter can actually wrap the incoming request and response objects to provide extra
functionality -- this
        at least wouldn't be possible in the case of a thread-local state object.
+         * [crazybob] Good point (Though it is possible with a thread local API. Your code
can set the thread local to your wrapped object and then restore the original object in a
finally block. Not ideal.) 
      * [craigmcc] "Interceptors need access to the servlet API" -- doesn't anyone care about
making it possible
        to write applications that work for portlets too?  I would hope that we all work towards
a world where
        direct access to the underlying servlet API objects is considered an anti-pattern.
+         * [crazybob] Another good point.
  
    1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better
name.
  
@@ -143, +147 @@

        * [jcarreira] I think it's great that you want to take the HTTP spec at its word...
most users don't care though.
        * [crazybob] I'm not arguing semantics. There are real security implications to using
GET when you should use POST, not to mention products like Google Web Accelerator will reak
havok on your site. As framework developers, we should make using POST as easy as GET for
users. To not help users do the right thing in this situation would be irresponsible, and
not in the letter of the law sense.
        * [frankz] Perhaps a new attribute on the <action> mapping?  type="view" or
type="update"?  This would really make the mapping of a specific various type, not the underlying
Action, which might be better because the type is abstracted from the actual implementation
and the Action class itself can house both types of functions (i.e., something like a !DispatchAction),
but the framework can know to treat them differently as appropriate.  I'm not one of those
"no XML config!" folks, I actually still prefer it to annotations, but having an analogous
annotation would be a good idea too.
+     * [crazybob] In addition to "view" and "update", we might want "chained view" and "chained
update". Can anyone else think of more "stereotypes?" Can you think of a better name than
stereotype? Strategy?
  
    1. On the OGNL value stack `#request` refers to request attributes and `#parameters` refers
to the parameters. We could rename these `#request` for request parameters and `#requestAttributes`
for request attributes.
  
@@ -178, +183 @@

  
    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)
+     * [crazybob] Regarding tool support, I like writing less code, and this doesn't preclude
using fully qualified class names if you still want to. Hopefully this new exposure will bring
us real tool support and this won't be an issue.
  
    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?
@@ -202, +208 @@

      * [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. 
      * [tmjee] -1 If possible please don't do so. I use it and like it. I guess (for me at
least), sometimes for simple validation it is nice to be able to just describe it (using xml
or annotation). Plus the validation could be tied to DWR for ajax support. Being able to write
custom validator is really cool. Please reconsider this. :-)
      * [frankz] -1 as well.  If you had said the validation framework could stand to be enhanced
and expanded on a bit, I'd agree, but I definitely think it should be there, not pointless
or stupid at all.  Declarative validation is a fantastic approach, especially with validator
being a separate Commons component.  For instance, we are working on a project at work that
is going to use Validator and the CoR implementation in JWP as the basis for a rules engine...
I put together a proof of concept showing how we could use the exact same validations in the
web front-end via AJAX calls as in the Web Service interface for other systems to call on.
 Being able to write those validations in XML without having to write actual code was a great
thing.
+     * [crazybob] I think sharing validations between AJAX and Java more than justifies the
framework. I would like to see us replace most if not all of the XML with annotations.
  
    1. Ditch xwork as a separate project, nobody uses it or cares about it
      * [jcarreira] You're kidding, right? We've discussed this already.... 
@@ -209, +216 @@

  
    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
+     * [crazybob] What needs to be done here? We wrote a type converter for enums. Is there
more to it?
  
    1. Clean up documentation. Focus on quality not quantity.
      * [jcarreira] Didn't you read the book? ;-)
@@ -230, +238 @@

       * [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.
+       * [crazybob] Actually, Ruby doesn't have annotations, but Rails leans heavily on the
`:foo` syntax to emulate 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.
+     * [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.
+     * [crazybob] "C[R]UD" isn't a good name because "view" == "[R]etrieve". Let's call it
"update" for the moment. What will the difference be between "update" and "action"? 
  
  == 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.
@@ -248, +258 @@

  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.
+ 
+     * [crazybob] I prefer an injection-based approach. You can use the `ScopeInterceptor`
which pulls an object of the session and passed it to your action. Or you can use Spring.
+ 
    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().
      * [frankz] This might well address the issue of !ActionContext being !ThreadLocal. 
If it was injected, it wouldn't need to be !ThreadLocal to get the same basic effect, and
maybe more importantly, it wouldn't automatically be available to helper classes as it is
as a !ThreadLocal.  That would address my concern about "inappropriate" usage of !ActionContext.
    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
      * [MJ] I see the following options when it comes to tags. (1) Use plain HTML + implicit
scoped variables like "actionName", "actionAddress", etc. to create dynamic values; this looks
pretty compact with JSP 2.0. (2) Use 1:1 relation between WW tags and HTML tags. (3) Use 1:M
relation between WW tags and HTML tags, like to create data entry form or a table. (4) Use
non-HTML-looking tags + more abstract attributes + "media" attribute, thus creating something
like JSF renderer for different media. Choosing between (1) and (2) I prefer the first one.
    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.
      * [frankz] +1.  This is one area where I personally think Struts had it right and we've
seen frameworks getting it "wrong" subsequently.  !ActionForward I believe is the right concept,
even if the realization might not be optimal.  I think the difference between return "ok";
and return new ActionResult("ok"); is pretty minimal, but the later opens up a lot of possibilities
being a true object that can have behaviors and properties and such.
- 
+     * [crazybob] There's no reason we can't support both `String` and `Result` return types
for action methods. I think we should encourage `String` though. Can you provide some example
use cases for when `String` isn't enough?
  
  == Nice to haves ==
  
@@ -300, +313 @@

    * [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.
    * [frankz] I think this is one of those things to be really careful about the perception
people may form.  If Action1 is going to continue to develop and be supported, even if to
a lesser degree, then forcing 1.5 for Action2 is probably fine.  However, I know at my company,
we are stuck on 1.4, and won't be changing for a long time.  I also know that we are not unique
in this regard.  If we can't move to Action2. so long as Action1 is still around and being
supported, that's fine.  But if we can't move to Action2 and it even '''seems''' like Action1
isn't getting enough attention, that wouldn't look so good to us.  Ultimately, if both can
be supported, I think that is still the best answer.  I definitely think the points made about
moving to 1.5 are totally valid, but I think that may lock out a lot of people who might otherwise
use Action2, so if that can be avoided, so much the better.
+   * [crazybob] Someone made the point earlier on that if a company is hesitant to switch
to JDK 1.5, they'll probably be hesitant to adopt SAF2, too. With a little time, 1.4 will
become irrelevant. I'm fine with supporting 1.4, but 1.5 should be the priority, and we shouldn't
let 1.4 support drive design decisions.
  

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


Mime
View raw message