Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
The SOB you are talking about is a well-respected (and present) colleague of mine and our team backed the decision, so the fun (which i was not observing as you did) ends exactly here :-( Robert Bill Bohnenberger schrieb: What an amusing thread. It seems to me the only problem here is the arrogant SOB that decided to defy the Bean naming conventions. LOL. (No offense intended if he is present company :) With affection, Bill On Thu, Nov 26, 2009 at 8:31 AM, Robert Graf-Waczenski r...@lsoft.comwrote: Rafał Krupiński schrieb: On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski r...@lsoft.com wrote: approach, which is tedious work because [...] i have to go through each applicable class and refactor-rename each method. Please don't try to make us feel guilty :-) You'll get paid for this, we're not. In previous post I stated clearly: If the only problem is the number of methods to be changed not If you can change only some classes. Well, yes, i am getting paid for this. So the time that i need to rename the methods costs my employer big money. This is a case of true backwards incompatibility and causes trouble in non-trivial projects such as ours. Other projects may decide to not upgrade from earlier Struts versions to V 2.1.8.1, which is something i would definitely take serious if i were working without getting paid, because having your stuff used by as many people out there as possible is a major point of FOSS, right? Freedom of choice is the other, meaning that we could of course stick with V2.1.6 and patch it to our liking. I personally voted against the latter option and decided to go for the renaming option because we need some other fixes that are available in 2.1.8. And, to tell the truth, our choice to use getmProperty() as accessor method naming pattern was a bad one originally but we lived with it since the beginning and are now being bitten in the behind :-) Robert - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
I agree to your observation, Dave. Point well made. I would like to get a comment from you about my claim about backwards incompatibility, though. Robert Dave Newton schrieb: Robert Graf-Waczenski wrote: And, to tell the truth, our choice to use getmProperty() as accessor method naming pattern was a bad one originally but we lived with it since the beginning and are now being bitten in the behind :-) That about sums it up, I think. I'm assuming the naming convention mProperty is designed to increase internal readability by showing that the property is an instance variable. Using the m convention in the getters/setters then propagates implementation details to the outside world, which defeats the purpose of getters and setters. Folks that use an underscore convention (_property) would name the getter getProperty, not get_Property or get_property. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: [OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Dave Newton schrieb: Robert Graf-Waczenski wrote: And, to tell the truth, our choice to use getmProperty() as accessor method naming pattern was a bad one originally but we lived with it since the beginning and are now being bitten in the behind :-) That about sums it up, I think. I'm assuming the naming convention mProperty is designed to increase internal readability by showing that the property is an instance variable. Using the m convention in the getters/setters then propagates implementation details to the outside world, which defeats the purpose of getters and setters. There's a bit more to the m than meets the eye. This is a legacy application designed for the Struts1 MVC form/model pattern with library code that transfers bean object properties to model object properties and vice versa. Now, since our form classes have far more methods that are only needed for the controller part of the application, we designed our bean-model transfer code around the presence of the m in the getter/setter method name (to avoid accessing controller-only getters and model utility methods). So even though your point about implementation detail propagation still stands, it is exactly this implementation detail that our application needs internally. Nowadays, of course, you would do the same thing much more elegantly with annotations, but back then, there were no annotations :-( Robert - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Hi, we are currently in the process of evaluating if upgrading our app from Struts 2.1.6 to 2.1.8.1 is feasible. Currently it is not because various things stopped working, but i'll like to work on one of them at a time. We frequently (*very* frequently, actually) use property names such as mProperty which are to be bound to class member variables of the same name and get/set via methods called getmProperty and setmProperty. This practice deviates from the JavaBean rules for property access, i.e. in this example, the getter would have to be called getMProperty and the setter setMProperty (each with a capital M). Struts 2.1.6 was able to map the property mProperty to calls to getmProperty and setmProperty, respectively. Struts 2.1.8.1 apparently does not have this leniency (or faulty behavior, depending on your POV...) and behaves strictly according to what Introspector.decapitalize() does. Since we (obviously) don't want to rename the myriads of getters/setters, i'd like to know if there is a way around this, maybe with a custom interceptor somewhere? Robert - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Robert Graf-Waczenski pisze: Hi, [...] Since we (obviously) don't want to rename the myriads of getters/setters, i'd like to know if there is a way around this, maybe with a custom interceptor somewhere? Hi If the only problem is the number of methods to be changed, maybe you should consider using a refactoring tool. -you do that only once -your code is kosher -you don't get performance overhead introduced by another interceptor Regards Rafał - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Hi, we do of course use a refactoring tool, but we are talking about a huge amount of methods. I'm not aware of a refactoring tool that would allow me to rename *all* methods in *one* step. Robert Rafał Krupiński schrieb: Robert Graf-Waczenski pisze: Hi, [...] Since we (obviously) don't want to rename the myriads of getters/setters, i'd like to know if there is a way around this, maybe with a custom interceptor somewhere? Hi If the only problem is the number of methods to be changed, maybe you should consider using a refactoring tool. -you do that only once -your code is kosher -you don't get performance overhead introduced by another interceptor Regards Rafał - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
I would think that is a feature of Struts that it requires proper OOP names. On Thu, Nov 26, 2009 at 8:01 PM, Robert Graf-Waczenski r...@lsoft.comwrote: Hi, we do of course use a refactoring tool, but we are talking about a huge amount of methods. I'm not aware of a refactoring tool that would allow me to rename *all* methods in *one* step. Robert Rafał Krupiński schrieb: Robert Graf-Waczenski pisze: Hi, [...] Since we (obviously) don't want to rename the myriads of getters/setters, i'd like to know if there is a way around this, maybe with a custom interceptor somewhere? Hi If the only problem is the number of methods to be changed, maybe you should consider using a refactoring tool. -you do that only once -your code is kosher -you don't get performance overhead introduced by another interceptor Regards Rafał - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org -- Saeed Iqbal http://www.iqbalconsulting.com Struts - J2EE - Application Architect / Developer
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Hi Robert, maybe not in one step, but for sure it's pretty easy to do. Just look for public [^ ]+ get[a-z] regexp in your codebase, and eclipse will do the rest, plus there's a bonus, You don't need to change anything in your jsp files. Ant to be absolutely sure everything worked well simply run all your tests after the refactoring. But of course it's for You to decide what to do. Best greetings, Paweł Wielgus. 2009/11/26 Robert Graf-Waczenski r...@lsoft.com: Hi, we do of course use a refactoring tool, but we are talking about a huge amount of methods. I'm not aware of a refactoring tool that would allow me to rename *all* methods in *one* step. Robert Rafał Krupiński schrieb: Robert Graf-Waczenski pisze: Hi, [...] Since we (obviously) don't want to rename the myriads of getters/setters, i'd like to know if there is a way around this, maybe with a custom interceptor somewhere? Hi If the only problem is the number of methods to be changed, maybe you should consider using a refactoring tool. -you do that only once -your code is kosher -you don't get performance overhead introduced by another interceptor Regards Rafał - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Well, i was hoping for an interceptor-based solution. But since something like this apparently is unavailable, i'm going for the method renaming approach, which is tedious work because i'm only changing the classes that are used by the Struts2 part of our codebase. So a global search/replace approach will not work, i have to go through each applicable class and refactor-rename each method. Robert Paweł Wielgus schrieb: Hi Robert, maybe not in one step, but for sure it's pretty easy to do. Just look for public [^ ]+ get[a-z] regexp in your codebase, and eclipse will do the rest, plus there's a bonus, You don't need to change anything in your jsp files. Ant to be absolutely sure everything worked well simply run all your tests after the refactoring. But of course it's for You to decide what to do. Best greetings, Paweł Wielgus. 2009/11/26 Robert Graf-Waczenski r...@lsoft.com: Hi, we do of course use a refactoring tool, but we are talking about a huge amount of methods. I'm not aware of a refactoring tool that would allow me to rename *all* methods in *one* step. Robert Rafał Krupiński schrieb: Robert Graf-Waczenski pisze: Hi, [...] Since we (obviously) don't want to rename the myriads of getters/setters, i'd like to know if there is a way around this, maybe with a custom interceptor somewhere? Hi If the only problem is the number of methods to be changed, maybe you should consider using a refactoring tool. -you do that only once -your code is kosher -you don't get performance overhead introduced by another interceptor Regards Rafał - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
On Thu, Nov 26, 2009 at 4:01 PM, Robert Graf-Waczenski r...@lsoft.com wrote: Hi, we do of course use a refactoring tool, but we are talking about a huge amount of methods. I'm not aware of a refactoring tool that would allow me to rename *all* methods in *one* step. jEdit should be powerful enough to open each java file in project directory, find all strings matching regex: ([sg]et)([a-z])Property\( replace it with: $1\u$2Property\( This should work for both getters and setters and make first character upper case, assuming you have get[1character]Property() pattern. All this in one step. -- Pozdrawiam / Best Regards Rafal Krupinski http://www.linkedin.com/in/krupinskir - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski r...@lsoft.com wrote: approach, which is tedious work because [...] i have to go through each applicable class and refactor-rename each method. Please don't try to make us feel guilty :-) You'll get paid for this, we're not. In previous post I stated clearly: If the only problem is the number of methods to be changed not If you can change only some classes. -- Pozdrawiam / Best Regards Rafal Krupinski http://www.linkedin.com/in/krupinskir - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Rafał Krupiński schrieb: On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski r...@lsoft.com wrote: approach, which is tedious work because [...] i have to go through each applicable class and refactor-rename each method. Please don't try to make us feel guilty :-) You'll get paid for this, we're not. In previous post I stated clearly: If the only problem is the number of methods to be changed not If you can change only some classes. Well, yes, i am getting paid for this. So the time that i need to rename the methods costs my employer big money. This is a case of true backwards incompatibility and causes trouble in non-trivial projects such as ours. Other projects may decide to not upgrade from earlier Struts versions to V 2.1.8.1, which is something i would definitely take serious if i were working without getting paid, because having your stuff used by as many people out there as possible is a major point of FOSS, right? Freedom of choice is the other, meaning that we could of course stick with V2.1.6 and patch it to our liking. I personally voted against the latter option and decided to go for the renaming option because we need some other fixes that are available in 2.1.8. And, to tell the truth, our choice to use getmProperty() as accessor method naming pattern was a bad one originally but we lived with it since the beginning and are now being bitten in the behind :-) Robert - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
What an amusing thread. It seems to me the only problem here is the arrogant SOB that decided to defy the Bean naming conventions. LOL. (No offense intended if he is present company :) With affection, Bill On Thu, Nov 26, 2009 at 8:31 AM, Robert Graf-Waczenski r...@lsoft.comwrote: Rafał Krupiński schrieb: On Thu, Nov 26, 2009 at 4:41 PM, Robert Graf-Waczenski r...@lsoft.com wrote: approach, which is tedious work because [...] i have to go through each applicable class and refactor-rename each method. Please don't try to make us feel guilty :-) You'll get paid for this, we're not. In previous post I stated clearly: If the only problem is the number of methods to be changed not If you can change only some classes. Well, yes, i am getting paid for this. So the time that i need to rename the methods costs my employer big money. This is a case of true backwards incompatibility and causes trouble in non-trivial projects such as ours. Other projects may decide to not upgrade from earlier Struts versions to V 2.1.8.1, which is something i would definitely take serious if i were working without getting paid, because having your stuff used by as many people out there as possible is a major point of FOSS, right? Freedom of choice is the other, meaning that we could of course stick with V2.1.6 and patch it to our liking. I personally voted against the latter option and decided to go for the renaming option because we need some other fixes that are available in 2.1.8. And, to tell the truth, our choice to use getmProperty() as accessor method naming pattern was a bad one originally but we lived with it since the beginning and are now being bitten in the behind :-) Robert - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
[OT] Re: S2 2.1.8.1: Need custom decapitalization (or leniency similar to 2.1.6)
Robert Graf-Waczenski wrote: And, to tell the truth, our choice to use getmProperty() as accessor method naming pattern was a bad one originally but we lived with it since the beginning and are now being bitten in the behind :-) That about sums it up, I think. I'm assuming the naming convention mProperty is designed to increase internal readability by showing that the property is an instance variable. Using the m convention in the getters/setters then propagates implementation details to the outside world, which defeats the purpose of getters and setters. Folks that use an underscore convention (_property) would name the getter getProperty, not get_Property or get_property. Dave - To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
