You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Sh...@ubs.com on 2006/01/23 18:47:23 UTC
Locale problem...
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:szabtam@gmail.com]
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 <fz...@omnytex.com> 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 <la...@holoweb.net> 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: user-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: user-help@struts.apache.org
> >>
> >>
> >
> >
> > --
> > Rick
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
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: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Locale problem...
Posted by Hubert Rabago <hr...@gmail.com>.
On 1/24/06, Niall Pemberton <ni...@gmail.com> wrote:
> However I have just created some new date validation functions that
> can do this for you. They are only currently in subversion, the
> package javadoc has some examples here:
>
> http://tinyurl.com/cc7a2
>
> Niall
>From above URL:
"1. Overview
Commons Validator serves two purposes:
To provide standard, independant validation routines/functions.
To provide a mini framework for Validation.
"This package has been created, since version 1.2.1, in an attempt to
clearly separate these two concerns and is the location for the
standard, independant validation routines/functions in Commons
Validator. "
Cool! Probably long overdue. Thanks for this, Niall!
Hubert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Locale problem...
Posted by Niall Pemberton <ni...@gmail.com>.
On 1/23/06, Shilpa.Nalgonda@ubs.com <Sh...@ubs.com> wrote:
>
> 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.
There isn't anything currently in Struts that handles this for you, so
you'll need to parse the date, handling the time zone yourself.
However I have just created some new date validation functions that
can do this for you. They are only currently in subversion, the
package javadoc has some examples here:
http://tinyurl.com/cc7a2
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org