[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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:
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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 -- * [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? ;-) @@ -291, +279 @@ * [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] @@ -318, +301 @@ 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
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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 -- * [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. :-) 1. Do we want to keep `ModelDriven`? + * [Gabe] Absolutely YES! `ModelDriven` allows us to build forms and populate the model without a prefix. It's simple. It also allows for security interceptors to zero in on one method for `ModelDriven` actions to determine what to secure. 1. Do we want `ValidationAware` (or its equivalent) to take message keys or actual messages. It takes the actual messages in WW2. `ActionMessages` in Struts takes keys. I'm a fan of keys; we would no longer need `TextProvider`. Pat suggested we take keys, and in the event that we don't find a message for the given key, pass the key along as the message. I think I'd rather fail fast. * [mrdon] Keys are fine, as long as you can do parameter replacement easily enough later. Not all apps need L18N, so I'm kinda against the fail fast. Perhaps in devMode, we add a clear warning? @@ -291, +292 @@ 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). + * [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
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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 -- 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. - * [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. + * [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) == 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. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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 -- 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'. 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. == Tim's Issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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 -- * [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. 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] 1. Address the confusing issue of the validation/workflow lifecycle and different methods (this is mentioned in more detail above, but it is something that is problematic). Right now we sort of hack it by making the input method a special case in webwork-default.xml. * [jcarreira] +1 : Carlos at G**gle had some good ideas for this... basically stuff like if your action method is foo() then you'd have prepareFoo() and validateFoo(), but then I added that the prepare() and validate() methods should be the defaults that we call for all action methods. * [crazybob] Interesting idea. Might be overkill (i.e. at that point, the user should probably create another action class). 1. Don't encourage lots of interceptor stacks. Ideally the normal user should never need to deal with them. It is better to have a larger stack that has optional features that could be turned on through annotations or marker interfaces than to encourage users to build their own stacks. * [jcarreira] I think we should have some pre-defined ones for standard things: view vs. CRUD vs. action - do somthing that's not CRUD. We should then use annotations to make it where you can declaratively associate a particular action method with a stereotype which is mapped to an interceptor stack, etc. + + == Gabe's Issues == + 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] + 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. + 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'. + 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. + + == Nice to haves == 1. Inheritance is not a good way to reuse code between actions. One work around is to use the strategy pattern to swap in different implementations of interfaces like `ValidationAware`. It would be nice if the framework had built-in support for mixins using cglib or Dynaop. For example, instead of extending a class that implements `ValidationAware`, SAF could extend an action class at runtime
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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] I'm not sure that's useful... We discussed it at some length on the mailing list and it wasn't clear. mapping the param interceptor twice isn't for that problem, though, it's for model-driven actions. * [crazybob] I'm not sure what you discussed, but it's *very* useful, and there should be no reason not to do it. Say for example my form has a 'userId' and fields to set on the user 'user.name', 'user.address'. With the sorting, 'userId' gets set first at which point we load a `User` object. Then the other parameters get mapped to that `User` object. Without the sorting, there's no guarantee on the ordering. You have to load the user in one action and then chain to another. This is a common use case; might as well make it simple. + * [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. == Nice to haves == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[Struts Wiki] Update of RoughSpots by GabrielZimmerman
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 -- * [crazybob] I'm not sure what you discussed, but it's *very* useful, and there should be no reason not to do it. Say for example my form has a 'userId' and fields to set on the user 'user.name', 'user.address'. With the sorting, 'userId' gets set first at which point we load a `User` object. Then the other parameters get mapped to that `User` object. Without the sorting, there's no guarantee on the ordering. You have to load the user in one action and then chain to another. This is a common use case; might as well make it simple. * [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. == Patrick's issues == - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
