On 7/25/07, Fowler, Perryn <[EMAIL PROTECTED]> wrote:
Ted, with regards to your idea below, It looks like a cool idea, but personally I don't like the idea of configuring things in a non-java file like that.
You can do the same thing with a Java class. It just has to extend ResourceBundle: * http://java.sun.com/j2se/1.4.2/docs/api/java/util/ResourceBundle.html Your could probably add the ResourceBundle interface to your existing JavaBean. The handleGetObject method would just call your getters. In this way, the name of the field could change without changing the key. To avoid inheritance clashes, one strategy would be to create a "wrapper" ResourceBundle implementation, and pass the JavaBean instance at runtime ("composition"). I'm not sure of the impact of the recent change, but. heretofore, validators could access message resources via OGNL expressions, which means they could access a ResourceBundle provided as a Java class. -Ted.
I guess I have 3 reasons 1) With my current approach, the fields are in a java object that is easy to reference anywhere I want. Currently I reference them in a number of places (my validation code, my integration tests, my views, etc) and I don't have to worry about locating and parsing a special config file each time. 2) It allows me to more easily write isolated tests for parts of my code without having to drag in the parts of the framework that deal with that config file. 3) For future maintainers, who may not be that familiar with the framework it is easier to trace through some java calls to see how things hang together than find out they need to look for a 'magic' config file. (For these reasons, we are currently not even using the validation xml files, but instead write java code that calls the various struts validators directly) Anyway, just my 2c Perryn -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ted Husted Sent: Wednesday, 25 July 2007 1:13 PM To: Struts Developers List Subject: Re: [ANN] Struts 2.0.9 General Availability Release with Important Security Fix On 7/24/07, Don Brown <[EMAIL PROTECTED]> wrote: > As to how we could support your use case, I'm not sure. Perhaps you could > use a JSP EL expression to resolve the field name as I believe JSP EL is > evaluated before Struts gets a hold of it. Another avenue might be to expose the fieldnames object as a message resource class and then use the key attribute. What I would really like to try sometime is adding a way to lookup a control name from a message resource, or somewhere, so that we could just list the fields. So, instead of <form> <s:textfield key="username" tooltip="Enter your user account name"/> <s:radio key="gender" list="genderList" tooltip="Select your gender"/> </form> We could do something like <form> <controls>username, gender</controls> </form> and centralize the details elsewhere username = User Name username.control = textfield username.tooltip = "Enter your user account name" gender = Gender gender.control = radio gender.tooltip = "Select your gender" gender.list = genderList -Ted. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] "This e-mail and any attachments to it (the "Communication") is, unless otherwise stated, confidential, may contain copyright material and is for the use only of the intended recipient. If you receive the Communication in error, please notify the sender immediately by return e-mail, delete the Communication and the return e-mail, and do not read, copy, retransmit or otherwise deal with it. Any views expressed in the Communication are those of the individual sender only, unless expressly stated to be those of Australia and New Zealand Banking Group Limited ABN 11 005 357 522, or any of its related entities including ANZ National Bank Limited (together "ANZ"). ANZ does not accept liability in connection with the integrity of or errors in the Communication, computer virus, data corruption, interference or delay arising from or in respect of the Communication." --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- HTH, Ted <http://www.husted.com/ted/blog/> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
