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 GabrielZimmerman: http://wiki.apache.org/struts/RoughSpots ------------------------------------------------------------------------------ * [jcarreira] You're kidding, right? We've discussed this already.... * [tmjee] -1 If possible, I'd like to keep xwork, not that I used it apart from WebWork but, I don't know, it's just good to have it there. * [rainerh] -1 as well + * [Gabe] -1 I believe XWork should be moved over to Apache and more importantly, the final decision on whether to do so should be made now rather than later. However, I don't believe it should be merged with the former webwork. + + ---- /!\ '''Edit conflict - other version:''' ---- * [phil] -1 + + ---- /!\ '''Edit conflict - your version:''' ---- + + ---- /!\ '''End of edit conflict''' ---- 1. Add java5 support to ognl. It's silly that it still doesn't handle enums (that I know of). * [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 + + ---- /!\ '''Edit conflict - other version:''' ---- * [phil] +1 * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + + ---- /!\ '''Edit conflict - your version:''' ---- + * [plightbo] +1 - we'll likely need to make new releases of OGNL to do this. That means it would be a good opportunity to also fix up other problems (Gabe probably knows the most about the limitations/problems here). + * [Gabe] +1 Hopefully, this would only be a modification in our PropertyAccessors to include enums. Here is one place where we will want to figure out a way that we can add these things but remain 1.4 compatible. + + ---- /!\ '''End of edit conflict''' ---- 1. Clean up documentation. Focus on quality not quantity. * [jcarreira] Didn't you read the book? ;-) @@ -276, +291 @@ * [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!) + + ---- /!\ '''Edit conflict - other version:''' ---- * [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. + + ---- /!\ '''Edit conflict - your version:''' ---- + + ---- /!\ '''End of edit conflict''' ---- 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] @@ -297, +318 @@ 1. Simpler XML Configuration of actions. Ted mentioned adding wildcard support for action names something like name="view*" where the wildcard can then be used elsewhere as a variable. Another idea is allowing one action configuration to extend another or having default action configuration that other action configurations can use. 1. Add the possibility of setting to the OgnlValueStack rather than pushing so we can get rid of using the context for user app variables and reserve it for framework variables. The user then wouldn't need to know anything about the context, just the stack. Also, this allows us to get rid of the '#' sign completely in expressions. Similarly remove the push tag to simplify the API. More detail here: [http://jira.opensymphony.com/browse/XW-329] and here: [https://issues.apache.org/struts/browse/WW-1133]. * [plightbo] I still don't know about this. My biggest concern is being able to do a fairly standard pattern of pushing an object on the stack (User) and then including a common snippet such as user-details.jspf. Without the stack and the ability to push, we might loose the loose coupling the value stack provides. + + ---- /!\ '''Edit conflict - other version:''' ---- + + ---- /!\ '''Edit conflict - your version:''' ---- + * [Gabe] Just wanted to make it important to clarify that I am not suggesting that we remove the ability to push on the stack, just remove the push tag to do it within JSPs. Thus, in your Interceptor etc you would still be able to push. Also, allowing the ability to set on the stack is a seperate issue. It would be powerful to be able to add dynamic names to the stack rather than only be able to use static method names to an object pushed to the stack. + + ---- /!\ '''End of edit conflict''' ---- 1. Hope I know what I'm talking about with this one: Provide a way that request parameters can be used as a form element value in case of error. If you submit a form with a text field that requires a numeric value but you enter a non numeric value and errors are returned, you lose the value entered when the type conversion happens. * [plightbo] We support this already (the value stack has an "overrides" map which gets set when type conversion errors occur). If this isn't the case, it's simply a bug :) 1. Remove OGNL Map attributes (and List/Set to be consistent) such as size, isEmpty, iterator. These can be accessed by size(), empty, and iterator() respectively and the way it works now you can never have myMap['size'] because it will just get the size not the value of the map with key 'size'. * [plightbo] +1, all I'd ask is that we try to make it feel as much like JSTL as possible. Not sure what that means, but just something to keep in mind :) + + ---- /!\ '''Edit conflict - other version:''' ---- + + ---- /!\ '''Edit conflict - your version:''' ---- + * [Gabe] I agree. OGNL is very much like JSTL already. I wonder if we can even add the few JSTL features OGNL doesn't have to OGNL and then position OGNL as an EL that "extends" JSTL. + + ---- /!\ '''End of edit conflict''' ---- 1. Allow indexable parameters similar to how it works in struts (with indexed="true") but being able to take advantage of XWork's advanced type conversion features. See: [https://issues.apache.org/struts/browse/WW-1189]. This is unfortunately not trivial at all. 1. Get rid of the use of static constant variables that are used in the key in the stack and accessed all over the place like XWorkNullHandler.CREATE_NULL_OBJECTS etc. I've started to do that with the OgnlContextState class, but it's not complete and I'm not sure if that's the best way to do it. 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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
