See responses in-line below...djsuarez -----Original Message----- From: Joe Germuska [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 05, 2004 2:40 PM To: Struts Users Mailing List Subject: Re: Enhancement requests
At 2:23 PM -0500 10/5/04, Hubert Rabago wrote: >http://issues.apache.org/bugzilla/ Actually, in general, I think it's better to have some discussion on the lists before filing bugs or enhancement requests, unless the issue is very clear. [<David Suarez>] [<David Suarez>] Makes sense. Will try to clarify below In this case, I'm not sure which dirty work David is suggesting that Struts handle. Is the issue with localized converters for things like dates? I'm not sure where else such an issue applies. [<David Suarez>] [<David Suarez>] The way I see it Struts does i18n work for Strings "out-of-the-box" with the ApplicationResources files. I would think it would make sense to do this for other i18n concerns, ie. dates. This can probably be done in a flexible way by using Locale's for example as default formatters but maybe creating some special format key names in ApplicationResources that Struts can use to know how to format dates, etc. Seems like a natural extension for Struts to finish handling i18n so that the developer can focus on business logic wiring and presentation. What would probably make the most sense would be for David to handle all his dirty work using Struts, and extending it where necessary to achieve a solution, and then present the solution to the Struts community for review and commentary. I don't say this as in "geez, David is so lazy," but more from the perspective that enhancement requests of this scope are always best discussed with more detail than he has yet provided, and often best using working code. [<David Suarez>] [<David Suarez>] I have some test code that I put together to test the theory (so it's not super pretty). You would want me to put it in Struts myself though? Hopefully this explains the app in enough detail and shows what I think may work. Basically these are the parts: A DateConverter class (didn't use DateLocaleConverter, can't remember what it didn't handle correctly would have to go back and check) to handle the form population into the appropriate bean location. My forms contain the business beans on them and the data all goes directly into the business beans. The only properties on the form are things that become lookups (ie. combo boxes) and cases where the business bean uses a List because Struts puts the property at the form level so I get the values there and set them directly onto the bean (don't store them locally on the form, just the method is there). I'm sure the security minded are nervous right now but I think it's easy enough to create a hash of the values that you don't want to change and then check them on re-submit to ensure they haven't. Now the problem with my code is that the form is populated before I have access to do anything by Struts (unless I were to extend Struts) so I am making the date format standard (US) and will convert it from the local version using javascript for now. Since struts gets the request first however, I do not see how it would be difficult for struts to either use request.getLocale() and or a key in the properties file (ie. dateformat.key) to know how to interpret the string date (either MM/dd/yyyy or dd/MM/yyyy for example) when it is populating the form. The DateConverter allows me to do this behaviour without interrupting anything or extending anything in Struts so I like that. Now if I have a server in the US, and requests coming in from various places I could not register one converter because by request it would differ where the request came from. Again, Struts having control before the form population would allow it to either a) replicate the beanutils function except at a per-request level or b) beanutils creates a second way to register a converter for the request (ie. a thread-local) or maybe a different method calls that says which converters to use. If David doesn't understand Struts well enough to achieve this goal, then hopefully he can do some research and post some pointed questions to the Struts users list until he has an idea of how to do it. If it turns out that Struts isn't flexible enough to support him achieving this goal, then lets make simpler and more general changes to Struts which promote extension in general, and save extensions for rather specific use cases until they've been tested in a running application or two. [<David Suarez>] Sounds good. The above is what I am doing for dates. If there is a better way, please suggest. I will have implemented the above this week for my app and it will only show the basics working. I hope the above shows the idea and someone can find it useful and general enough that it can become part of Struts in the future (someone else can implement the above in Struts). I wouldn't have the time to implement it in Struts to show as I don't know the Struts code so it would take me a while to ramp up on that to start with. I am hoping this eventually leads to making struts fully i18n aware out of the box. Seems like the i18n questions on this list are the same and probably the others could also be added to struts without any real pain (ie. the filter to set the encoding). I would think that could also be part of struts instead of everyone using the same filter. All these i18n features can be bundled maybe into a property that people set in struts-config (ie. need-i18n) so the extra work only applies to those folks that set it to true for example. I would start by pointing out that in general, the RequestProcessor is designed for extensibility, and for a local solution you could probably start by extending it. It is well understood that the single-inheritance limitations of RequestProcessor make this a difficult way to make a general solution available to the rest of the Struts community -- but the struts-chain RequestProcessor is available already for those who are interested in applying it and developing more generalized extensions to the Request Processing chain, and we do intend to steer Struts to using the chained request processor as the base implementation as one of the next major changes -- but you certainly don't have to wait, as you can already use it, and in fact, it needs more people to use it to flush out any bugs in the adaptation of the existing RequestProcessor functionality. I hope this helps, Joe [<David Suarez>] It definitely does help. If at some point in the future I have time, I will look at the Struts code and be able to provide the working ideas within Struts. Right now considering my schedule that's pretty impossible. So for now, let me know if there's anything unclear that may help someone else visualize better how it could function that would have the time to write the code for Struts. What I was hoping to achieve out of the question was some feedback on if the approach is valid (I can see that it will work with my sample app) but not sure if there is an alternative cleaner way. If there is, I would love to hear it as again I am going to be doing this during the week. To hide the one format date from the user I will be using a javascript date-picker so that the user sees the date how they're used to seeing them and I can populate the hidden US format (maybe I can use milliseconds instead). Anyways, if someone sees some great pitfalls with this approach I would appreciate the feedback. The one alternative I have heard so far is to use Strings in the form to handle dates for i18n. Right now I think it may be less work/risk to have it handled during the form population but I could be wrong. Please advise. Last but not least, I think i18n out of the box would be a good goal for Struts for some future version. From this list it seems like everyone who has the requirement is doing pretty much the same thing from what I've read so far. Thanks!...djsuarez > >On Tue, 5 Oct 2004 14:21:50 -0500, David Suarez ><[EMAIL PROTECTED]> wrote: >> How does one go about requesting an enhancement to Struts? >> >> For my particular problem today it seems like Struts could handle all >> the dirty work for me if it used a version of bean utils that could be >> registered "per request". Struts could then set the Locale and then >> populate all of the fields. I guess this would be a bean utils >> enhancement as well. >> >> Is there one-point place that the above can be suggested? I think the >> benefit of this is that Struts can host business beans directly and >> get/set them fully requiring less developer intervention to handle >> relatively mundane formatting details. This would be less code to be >> written as well. >> >> Thanks!...djsuarez >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "In fact, when I die, if I don't hear 'A Love Supreme,' I'll turn back; I'll know I'm in the wrong place." - Carlos Santana --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
