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

------------------------------------------------------------------------------
      * [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!
      * [tm_jee] I think this is pretty use case specific as well, but a 
progress monitor ui component would be nice. 
+     * [jcarreira] If we agree that supporting file uploads out of the box is 
important, then this is just a nice feature for that support to let the user 
know how much of the file has been uploaded, etc.
  
    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
  
@@ -280, +281 @@

    1. Specify and simplify Interceptor scope. Currently, you have an 
Interceptor that calls actionInvocation.invoke() and then returns a different 
result than actionInvocation.invoke() returns, the actionInvocation.invoke() 
result will be used anyway. This is confusing and muddies the meaning of the 
Interceptor API, which IMHO should simply wrap the action not the action all 
the way through to the end of the result. The reason it's set up the way it is, 
as I understand it, is so that Interceptors can clean up resources like 
connections after the result is returned. However, I wonder if we can implement 
a request based object that can take care of such resources and destroy them at 
the end of the request rather than using Interceptors in this way.
       * [crazybob] That was really surprising and confusing to me at first, 
too. I thought it would have been more intuitive for the result to run after 
all the interceptors returned. I'm not sure whether we should change it or not. 
I like the idea of interceptors being able to clean up after results a lot more 
than I like the idea of an interceptor being able to return a different result.
       * [Gabe] It is an advantage for Interceptors to be able to clean up at 
the end of a request, but it isn't great how they do that either. Take for 
example an action chain. If you have a create connection Interceptor 
surrounding each of the chained actions, you will open two connections, which 
besides being wasteful could cause problems with other resource types. I wonder 
if we can create some sort of request scoped ResourceManager class that can 
allow Interceptors to create resources or access them if they exist and specify 
how they should be destroyed at the end of the request. Thus in the connection 
case, the Interceptor could check if the resource manager had one and if not 
create it and add it to the resource manager for other objects to use. (Another 
option of course is an inversion of control approach)
+     * [jcarreira] Interceptors can still change the result... Implement 
PreResultListener and in your callback, change the resultCode and voila! The 
result executed will be changed. The PreResultListener interface lets you 
register your interceptor to get a callback after the action and before the 
result is executed. Oh, and on the ConnectionInterceptor -> It's just like AOP. 
You have to check if it's been done already and know not to create a new one or 
close it on the way out. I do this all the time in AOP interceptors, so why 
should this be different? Personally, I'd rather use the same connection across 
all of the actions in a chain than clean it up after each one and use a new one 
per action. For request scoped resources, take a look at Spring's scoped 
components. I'm using them at work and they work pretty well (a few issues I'm 
working through with them notwithstanding). 
  
  == Tim's Issues ==
  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.
@@ -288, +290 @@

  
      * [crazybob] I prefer an injection-based approach. You can use the 
`ScopeInterceptor` to pull an object off the session and pass it to your 
action. Or you can use Spring to inject session-scoped objects into your action 
(though I would avoid Spring personally).
  
+     * [jcarreira] I can attest that the Spring scoped components work well 
with WebWork. It's what we use at work for maintaining session or request state.
+ 
    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.
+     * [jcarreira] I think this is a bad idea, in general. Actions should 
specify the exact things they need and have them supplied, not just ask for the 
"world" (the ActionContext is the world the action lives in). 
    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.
+     * I'd encourage people to give the ww: tags a spin... they're really much 
more powerful than the JSTL or previous struts tags and you don't need so many 
tags to do things. On being closer to HTML attributes, do you have some 
examples?
+ 
    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?
@@ -300, +307 @@

      * [crazybob] I'm not sold on this. 1) The result pulls values from the 
value stack, not the request attributes. 2) I ran into a case recently where I 
''thought'' I wanted to return a real object at first: I wanted the action to 
dynamically select a redirect URL. I ended up doing this: {{{
    <result name="..." type="redirect">${url}</result>
  }}} 3) Enabling users to return either a real object or a string is going to 
impact the interceptor API, too. :( 4) Wait a second... you can do what you 
want right now! Create a new result type which looks up a `Result` object on 
the value stack and delegates to it. Then map a global result to the new type. 
For example, you could return `CUSTOM`, and the the result type would execute 
the `Result` returned from `getCustomResult()` on your action. ;) 
+     * [jcarreira] -1 I've never, ever seen anything that needed this, and it 
makes the API requirements on the action classes more tightly coupled. Result 
configurations and Result instances can pull values from the value stack 
(including but not limited to action properties) so you can easily set up any 
of the values you want to give the result as properties of your action and have 
them pulled. 
  
  == Nice to haves ==
  

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

Reply via email to