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 tmjee: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ </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. - * [tm_jee] XHTMl them is currently the default, if not mistaken. + * [tm_jee] XHTML theme is currently the default, if not mistaken. 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 @@ -282, +282 @@ * [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!) * [phil] I'd like to be able to reconfigure my application without the need for recompilation. If annotations support that (or if we're using an xdoclet/generator approach), then I'm all for it. Otherwise, keep the xwork.xml file - it's clean, simple and to the point. + * [tm_jee] I agree with Phil, I still like configuring through configuration without recompilation. 1. Fail fast with detailed error messages, ideally ones that show you what you did wrong and what you should to. @@ -338, +339 @@ * [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). * [mrdon] While I agree more specific is generally better, I like the idea of the user being able to subclass ActionContext for their particular application. Tapestry has the Visit object (I think that's the name) I've always liked. * [plightbo] Tim's suggestion of allowing actions to get the ActionContext without referencing the thread local is a good one. This is in line with other requests to reduce the number of situations where users have to deal with ThreadLocals. + * [tm_jee] I think its ok, if we allow action to implements say ActionContextAware and have an interceptor "inject" the ActionContext into it. 1. HTML analog tags should stick to HTML attributes. I don't 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. * [jcarreira] 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? * [mrdon] +1 for aligning attributes with HTML attributes + * [tm_jee] -1. If I'm not mistaken I think WW's tag are doing stuff in a broader perspective, typically in a theme perspective and I hope we could still keep it that way, if possible. A textfield for example, merely says its a textfield, how it behaves is entirely up to the particular theme. Normally, one would extends from a parent theme, and overide those components' template that they want alteration accordingly or introduce other templates that could co-exists with their counterparts to skin the component. 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. @@ -382, +385 @@ }}} If the user doesn't call a result method, we would use an intelligent default. You could implement this using an interceptor and an action support class. However, I'm with Jason: I've never needed this and I like the seperation. * [plightbo] Bob: your suggestion doesn't seem very "user friendly". I think we should really think long and hard about doing this. I'll be the first to admit that much of the reason I never thought about doing it in WebWork was purely to be "anti Struts" (sorry!). I've grown up a bit since then. The downsides I can see to this are: 1) more confusing if we offer both options, 2) views are tightly coupled to the action with no easy way to override, 3) support for both could cause problems with overriding actions, and 4) tool support, such as graphing out page flows, would be difficult or impossible for actions that use this technique. However, there are good positives for this, as already mentioned. Let's give this some real consideration. * [jcarreira] Rather than make the framework deal with this, let's make an Action superclass or interceptor, etc which can handle this. How about an interface with one method: + * [tm_jee] I'd rather prefer to introduce an interceptor as well. Result getResult(); --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
