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 ------------------------------------------------------------------------------ * [jcarreira] A new instance per action configuration, right? Not per-invocation... * [crazybob] Last I tested it was per invocation (I remember because it surprised me). This is actually a non-issue. We'll create a custom `ConfigurationProvider` for Struts which won't have this problem. * [plightbo] Agreed, by abstracting most configuration out, we can control the lifecycle. I think the lifecycle should be either once per interceptor or once per invocation. Currently the implementation is too cumbersome (once per unique action configuration). + * [tm_jee] I'd prefer to keep them as a separate optional implementable interface as Bob advised, such that Interceptor interface implementor are not required to implement them, and for the minority who needs them, its there. 1. Get rid of `AroundInterceptor`. Having `before()` and `after()` methods doesn't make things simpler. It reduces flexibility. We can't return a different result. You can't handle exceptions cleanly. The actual interceptor class doesn't appear in the stack trace (we see `AroundInterceptor` over and over). @@ -99, +100 @@ 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. @@ -111, +113 @@ * [crazybob] Does "specified" == "documented"? Can you elaborate on "easily knowing when you're done" and why we can't address that use case with one interface? We should expose the user to one interface: `Invocation`. We can have as many objects as we like when it comes to the internal implementation. * [plightbo] Big +1. I would add the ValueStack to this list as well. Let's have one object for each invocation, and also make "sub invocations" (chaining or ww:action calls) a first class citizen through child/parent invocation relationships. * [jcarreira] Let's have an interactive design session on this... I'm not sure it's as easy as you think to merge them all into one (although behind one interface should be doable). + * [tm_jee] Sorry, I don't get this bit. :-P We could just expose ActionInvocation. ActionProxy could be obtained from ActionInvocation. Or maybe just expose ActionProxy's method in ActionInvocation, but actually its just delegating to ActionProxy. Did I miss something? 1. Should `ActionInvocation.getResult()` recurse over chain results? Maybe we should have two methods? `getResult()` and `getFinalResult()`. Is there a good use case for this? @@ -129, +132 @@ * [mrdon] I dunno, are you planning to make protected getters/setters for every field? I've found protected fields to be invaluable when extending frameworks (again, subscribing to the believe we should let the user do what they want and not artifically restrict them). I do wish you could declare the fields _only_ available to subclasses and not to the whole package. * [crazybob] Absolutely, methods instead of fields. Methods enable us to hook access if need be, change the underlying implementation, manage thread safety, protect our own code against unexpected conditions/states, etc. Fields are OK within a package, but when it comes to public APIs, better safe than sorry a year from now. * [jcarreira] Oops, I was translating "fields" -> "properties" and thinking of getters and setters. + * [tm_jee] I am kindof thinking in the same line as Don. 1. Rename `ActionInvocation` to `Invocation` or `Request`. Shorter is better. @@ -140, +144 @@ * [plightbo] The name doesn't bother me, but the implementation is far too complex. I would propose we cut it down from all the crazy package/interface/model-driven stuff we have now to a simple i18n RB loading approach that uses 0 or more global bundles as well as bundles associated with the _view_ (NOT the action, since that never made much sense). * [mrdon] I'd like to see this re-evaluated as well. For one, I want to make it easier to provide an impl that gets messages from a Struts bundle, which really isn't possible now. * [jcarreira] +1 to simplifying. We started with lots of separate resource bundles for per-action texts, but we're moving to one resource bundle per module. It's too much hassle. + * [tm_jee] I like the feature WebWork has that allows resource bundle to be overriden at different levels through inheritance hierarchy, package hierarchy and a global level. If possible, please keep them. :-) 1. Come up with a clean way to separate "view" actions from "update" actions. For example, we might have `view()` and `update()` methods in the same action class. Right now XWork has `MethodFilterInterceptor`, but that's not a very clean solution. Do we want validation or the `DefaultWorkflowInterceptor` to run for the `view()` method? One solution is separate interceptor stacks, but it would be nice if there were some first class support for this. We could flag action invocations as "view" or "update" (using an enum). We could automatically choose a mode based on whether the request is an HTTP GET or POST. Or we could set the mode based on an annotation on the action method. Or some other way... @@ -152, +157 @@ * [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. * [jcarreira] That one always has been confusing... * [mrdon] Or #requestScope keeping in line with JSTL/JSP * [rainerh] +1 for JSTL/JSP like naming + * [tm_jee] +1 for JSTL compatible naming as well. 1. Warnings and failing silently is not the best practice. For example, if we can't find a method in a given action class, blow up ASAP (at load time). We shouldn't be fuzzy and do stuff like try to find a method named `doXxx()` when we can't find a method named `xxx()` (WebWork had backward compatibility restrictions, but we don't need to perpetuate them). * [plightbo] +1, everything should be much more proactive about failing fast and failing with a nice error message. * [mrdon] Agreed, and we have done a lot of work lately on this issue. * [rainerh] Better error reporting for developers is a very important issue. Latest additions to xwork will help here but could be improved a lot. + * [tm_jee] +1 1. Add better support for file uploads. * [jcarreira] Anything specific? We're using them at work and they work well... Maybe we could pull out the file upload progress bar with DWR thing that we've got here... * [crazybob] We have an `UploadedFile` value object which has properties for the `File` object, the file name in the form, the content type string, and the name specified by the user. An interceptor passes that object to a setter on our action and then deletes the file at the end of the request. * [plightbo] +1 for a compound object that holds the data, file name, and content type. The file shouldn't be represented by java.io.File, but some other wrapper object. That way people can implement in-memory options if they choose to. + * [tm_jee] +1. I like the idea of Compound File Upload object as well. 1. Don't eat/wrap exceptions. Throw them through to the container. Don't eat exceptions that occur in getters. @@ -183, +192 @@ * [Gabe] Discussion here: [http://forums.opensymphony.com/thread.jspa?messageID=32084] Basically, I think we can come up with a better way to accomplish this than requiring setter methods to be used for business logic and depending on parameter ordering. * [plightbo] As Gabe said, we already discussed this. And the last post on the subject was that we should do it. We still should. * [Gabe] I've created an XWork JIRA for a solution to the same use case here. [http://jira.opensymphony.com/browse/XW-387] I'd be happy to contribute the code. + * [tm_jee] What about a new parameter interceptor that does this functionality and users could switch between these interceptor according to their needs instead of reimplementing current parameter interceptor. Or have a switch in the current parameter interceptor to allow it to switch strategy of populating parameters. 1. Allow paths in action names. For example `<action name="reports/myreport">`. * [jcarreira] Why do you want this? Isn't this part of the namespace of the action? @@ -201, +211 @@ </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. 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! + * [tm_jee] I think this is pretty use case specific as well, but a progress monitor ui component would be nice. 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 1. Defaults should be JSP all the way. People know it and like it, despite all the limitations. Allow for other view technologies, but don't force people to learn stuff they don't want to. Learning ww is enough of a pain as it is + [tm_jee] Hmm... are you suggesting that we should support JSP template as well? WebWork currently does support JSP view, just theat there's no theme/templates written in JSP due to JSP not being able to be packaged and displayed from a jar file in the classpath. 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. @@ -226, +239 @@ * [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? * [rainerh] +1 as well + * [tm_jee] +1 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) + * [tm_jee] +1 What do you think about the reference docs, we put a lot of effort in it. Of course there's still lots of room for improvement. We'll continue to do our best. :-) == Patrick's issues == @@ -336, +351 @@ * [gdinwiddie] WRT "if a company is hesitant to switch to JDK 1.5, they'll probably be hesitant to adopt SAF2, too," I don't think that's necessarily true. In companies where I've worked, the choice of what libraries are used for app development are often made by the developers of that app, but choice of app server (which dictates JDK version), is generally made at a higher level, and often by a slow-moving committee. * [crazybob] You're right. That's actually been my experience, too. I'm fine with supporting 1.4 (though I'd prefer not to have to write the code as I haven't used it for some time). * [rainerh] +1 for Java 5 support + * [tm_jee] +1 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
