[Struts Wiki] Update of RoughSpots by FrankZammetti

[Apache Wiki]

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

--
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?
+ * [frankz] A few that come to mind... the ability to choose between 
redirect and forward based on decisions made in code (you could argue that you 
can have two result's defined, one with type redirect and one with type 
forward, but then that starts to clutter the config file I think)... the 
ability to add parameters to a forwarded result (i.e., if you wanted to forward 
to another action, how can you add parameters just by returning a String?  
Well, unless the processor expects and can deal with a query string appended I 
support)... the ability to add an anchor name to the response... the 
opportunity to include additional objects in the response (i.e., what if you 
had some sort of ViewSupport object that the presentation can make use of... it 
might be more intuitive to add it to a Result than to directly add it as a 
request attribute, and that also makes for better abstraction from the servlet 
API).  I'm sure there's more, and I'm sure there are ways to accomplish most
  of these things without returning an object, but I think the clarity of the 
resultant code is greater by returning a Result object, and it opens up 
possibilities I can't think of (i.e., functionality encapsulated in that object 
independant of tbe interceptor stack).
  
  == Nice to haves ==
  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[Struts Wiki] Update of RoughSpots by FrankZammetti

[Apache Wiki]

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