[Struts Wiki] Update of "RoughSpots" by FrankZammetti

[Apache Wiki <wi...@apache.org>]

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 FrankZammetti:
http://wiki.apache.org/struts/RoughSpots

------------------------------------------------------------------------------
      * [plightbo] By running our interceptors and other objects through the same factories and lifecycle managers that the action classes go through, this should be a non issue.
      * [mrdon] This I'd like to see.  I've found myself using these objects so often in wierd little places, I'd be loath to remove them unless we could prove 100% that their information can be retrieved elsewhere.
      * [jcarreira] +1 to Patrick's point... we may need to introduce some more advanced *Aware interfaces, though, to give people access to the guts if they really want it.
+     * [frankz] !ActionContext being !ThreadLocal was one of the first "cool" things I noticed about WW.  I'd hate to see that change.  The only thing I can think of that would make me agree to change that is that I think we may find developers using it in "inappropriate" ways, i.e., an Action calls a business delegate and the delegate uses !ActionContext.  My bet is most people would agree it should be a "best practice" to not do that.  Still, it's cool that you can!
  
    1. Is `ValidationAware` a good name? Perhaps `Errors` or `ErrorList` would be a better name.
  
@@ -117, +118 @@

        * [crazybob] Triggering an event should still be a POST (though the framework should make it easy). From the HTTP spec.: "GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval."
        * [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.
  
    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.
  
@@ -155, +157 @@

  
    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?
+     * [frankz] I would ask what "real AJAX work" means, because that would really determine what path makes sense.
  
    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>
@@ -165, +168 @@

  
    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
+     * [frankz] Just an opinion, but this seems to me too specific a use case for a framework to encapsulate.  I think having an example showing how to do it, perhaps what jcarreira has done at work, would be great, but I for one wouldn't like the framework offering this out of the box... I think it is possible for a framework to be able to do TOO much!
  
    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
  
@@ -173, +177 @@

    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. 
      * [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.
  
    1. Ditch xwork as a separate project, nobody uses it or cares about it
      * [jcarreira] You're kidding, right? We've discussed this already.... 
@@ -192, +197 @@

    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?
      * [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.
+     * [frankz] I for one have zero problem with annotations being an option, even being the default, but do keep in mind that not everyone sees annotations as really being that great of an idea.  I acknowledge it might the minority view now, but I for one see it as configuration information scattered throughout the code base, rather than in one known location (read: XML config file), so speaking for myself, I am not entirely sold on annotations being superior to XML config files (assuming the config files aren't overly complex that is!)
  
    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]
@@ -219, +225 @@

  
    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.
    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.
  
  
  == Nice to haves ==
@@ -267, +275 @@

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

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