Hi All, I have an application which is used in US, Europe and Asia. The application should show the date in each regions own local time. I have to create the time and store it in databsae in GMT and again while displaying the date back to the browser convert The GMT into the local timezone. What Is the besy way to achieve this, My application is Struts based. Can I capture the browsers locale in the jsp and pass it to the backend and convert it into GMT to insert into database...
Thanks for any suggestions. -----Original Message----- From: Tamas Szabo [mailto:[EMAIL PROTECTED] Sent: Monday, January 23, 2006 11:56 AM To: Struts Users Mailing List Subject: Re: Validation Security Hole? But what do you guys mean by lookin for a canceled method in the Action. I think that the best would be to implement a Cancelable interface if your Action is cancelable. You would have to do this in all kind of Actions (DispatchAction too) by the way. Or is having interfaces very unstrutsish? Tamas On 1/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > On Mon, January 23, 2006 9:54 am, Rick Reumann said: > > The solution I would like to see is if the canceled param is passed > > to the Action, it tries to look for a "canceled" method in the > > Action. I know this makes the Action like a DispatchAction but in > > this regard I don't think the non-Dispatch folks would disapprove > > too much. In other words, execute is never performed (not is a > > dispatch method performed) only the 'cancelled' method is looked > > for. Validation is skipped as usual for this cancelled method. This > > is better than having to use the current "isCancelled" since you are > > never in the your Action's execute or Action dispatch method. > > I'm in the non-DispatchAction camp myself (although who knows, I may > be the only one in that camp!) and I don't have a problem with this. > > > What do you guys think about just making sure a "cancelled' method > > is looked for when canceling? The problem will be that this won't be > > backward compatible now that I think about it. Blah oh well. I > > tried:) > > That would be my only concern is backwards-compatibility. Then again, > simply adding the method to the Action class should deal with it > always being present. I would also suggest a default implementation > that returned null but that rendered a response like so: > > <html><head><title>cancel() not present</title></head> <body>No > cancel() method found in requested Action</body></html> > > At least that way it's not just a blank screen, the hole is plugged, > and a developer will know what's going on pretty quickly and easily (a > nice log message in the default implementation saying what the > requested Action was would be nice too). > > Anyone legitimately using isCancelled() functionality would have to > move that related code to cancelled() now to have it all still work, > but I tend to think that's a relatively small group of people being > hurt... I for one would find this solution acceptable. > > Frank > > > The description by Laurie below is > > On 1/22/06, Laurie Harper <[EMAIL PROTECTED]> wrote: > >> [Moved to a top-level thread, as this doesn't have anything to do > >> with (either of) the thread(s) it was nested in! :-)] > >> > >> > >> I think this thread deserves discussion on the dev list, but before > >> I move it over I thought I'd post a summary to make sure I've > >> captured > all > >> the arguments. I've also added preliminary thoughts in how to > >> resolve the issue at the end of this post, though that discussion > >> definitely ought to proceed on the dev list I guess. > >> > >> I'll re-post this message to the dev list later today if I haven't > >> missed anything important below: > >> > >> > >> > >> * Issue: addition of a 'org.apache.struts.action.CANCEL' parameter > >> to any request will cause validation to be skipped, but the rest of > >> the request processing / action invocation cycle to proceed > >> normally > >> > >> * Consequence: any action which proceeds assuming that validation > >> has completed successfully and which doesn't explicitly check > >> isCanceled() is proceeding on a broken assumption > >> > >> * Questions: > >> > >> - why doesn't Struts call validate() on a cancelled request? > >> > >> If a request is canceled it usually means validations don't > >> apply since the implication is that any user input will be > >> thrown away. Users shouldn't be required to supply valid > >> inputs for actions they are canceling. > >> > >> - why does Struts still call Action.execute() for a canceled request? > >> > >> Since you may still want to act on a canceled request (e.g. > >> to clean up resources stored in the session). (Some of?) the > >> DispactAction variants dispatch to a special method and aren't > >> subject to the consequences listed above, but most action > >> implementations don't. > >> > >> - why does Struts still populate the action form on a cancelled > request? > >> > >> If inputs are going to be thrown away anyway, why process > >> them by populating the action form? [Commentary: I believe > >> this behaviour makes sense since it preserves a standard > >> way to access the request data, should you want to, regardless > >> of whether the action was canceled. You could argue that > >> either way...] > >> > >> > >> Here's my first thoughts on possible approaches to addressing the > >> problem, to kick off further discussion on the dev list: > >> > >> - SAF1.2 and before: ? document, don't fix? add config req'm'ts on > >> action mapping? Refer to discussion on user list for various options. > >> > >> - SAF1.3+: make cancel processing a command which you have to > >> include > in > >> your request processing chain, and perhaps disclude it by default? > >> [I'm not familiar enough with how you deploy chains on a per-action > >> basis to know if this is the right way to do it...] > >> > >> - WW2/SAF2: implement cancel processing as an interceptor and > >> either disclude it from default stack or require an action to > >> implement an interface declaring that cancel processing should happen? > >> > >> L. > >> > >> > >> ------------------------------------------------------------------- > >> -- To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > -- > > Rick > > > > -------------------------------------------------------------------- > > - To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Visit our website at http://www.ubs.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
