Accessing Struts beans with keys defined in the Globals class

Hello everybody, I hope it's not a trivial question. I'm trying to access the current Locale from a JSP page. The key to access the Locale is stored in variable org.apache.struts.Globals.LOCALE_KEY. So what I did is to look up the value of the variable in the source file

Re: Accessing Struts beans with keys defined in the Globals class

try this session.getAttribute(Globals.LOCALE_KEY); --- Denis Laroche [EMAIL PROTECTED] a écrit : Hello everybody, I hope it's not a trivial question. I'm trying to access the current Locale from a JSP page. The key to access the Locale is stored in variable

Re: Accessing Struts beans with keys defined in the Globals class

: Subject: Re: Accessing Struts beans with keys defined in the Globals class 03/26/2004 11:43

Re: Accessing Struts beans with keys defined in the Globals class

At 1:03 PM -0500 3/26/04, [EMAIL PROTECTED] wrote: Thanks, but is there a way to do it without using Java code directly in the JSP page? In this cases there is not, although this has been discussed just today on struts-dev: http://article.gmane.org/gmane.comp.jakarta.struts.devel/18429/ In

Re: Design decision for Globals class

Craig R. McClanahan wrote: Typesafe enums make sense when the underlying data really is an enumeration of values that represents the total set of valid inputs to a method. This is true, for example, when the constants are the integer subscripts into a fixed size array, and you want to avoid the

RE: Design decision for Globals class

be). Justin -Original Message- From: John Cavacas [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 29, 2003 7:43 PM To: Struts Users Mailing List Subject: Re: Design decision for Globals class I agree with David. Constants should be defined where they are relevant. But once you start using

Re: Design decision for Globals class

think it should be). Justin Constants are not always owned or strongly related to any particular class -- in those scenarios, you definitely want to move to a common one (like we did with Globals in Struts 1.1). It can also lead to cleaner imports if you only have to import one class to get

Design decision for Globals class

Hi, A colleague of mine and I are discussing the relative merits of having something like a Globals class. I argue that it removes the constants from their proper association with a parent/owning class, ignoring the concept of object orientation and losing a self-documenting aspect regarding its

RE: Design decision for Globals class

session.setAttributes() a lot:). -Original Message- From: Justin Mahoney [mailto:[EMAIL PROTECTED] Sent: October 29, 2003 4:10 PM To: 'Struts Users Mailing List' Subject: Design decision for Globals class Hi, A colleague of mine and I are discussing the relative merits of having something like a Globals

Re: Design decision for Globals class

In general, constants should be defined in the class they're relevant in. The Struts Globals constants used to be defined in Action; however, they're used in many places other than Action so it made sense to move them to the new Globals class. David --- Justin Mahoney [EMAIL PROTECTED] wrote

Re: Design decision for Globals class

:15 PM 29/10/2003 -0800, you wrote: In general, constants should be defined in the class they're relevant in. The Struts Globals constants used to be defined in Action; however, they're used in many places other than Action so it made sense to move them to the new Globals class. David --- Justin

Globals forwards with LookupDispatchAction

I'm using lookup LookupDispatchAction and to ease development, I've defined each of my CRUD methods as a global-forward. For example: forward name=editProfile path=/editUser.do?action=Edit/ However, the problem is that this doesn't work with i18n. What I'd like to do is to have it dynamically

Globals Exceptions

Can someone explain the decision to not make global-exceptions active for all of the processing in RequestProcessor.process()? Why only on handling the action, processAction()? Scott Tinsley System Administrator Defense Commissary Agency 804-734-8857

Re: Globals

On Thu, 26 Sep 2002, Anthony Martin wrote: Date: Thu, 26 Sep 2002 19:58:11 -0700 From: Anthony Martin [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL PROTECTED] To: Struts User List (E-mail) [EMAIL PROTECTED] Subject: Globals Is it now recommended to use members of Global

Re: Globals

I would use the constants from Globals. That text sounds very much like the Action constants will be deprecated. It doesn't make sense to define the constants in 2 places so one of them has to go. Dave From: Anthony Martin [EMAIL PROTECTED] Reply-To: Struts Users Mailing List [EMAIL

Globals

Is it now recommended to use members of Global like in Global.ERROR_KEY instead of Action.ERROR_KEY *even* in classes that extend Action? I know these members have not been marked as deprecated, but the note seems to indecate that they are preferred: Global manifest constants for the entire

RE: [Core] Setup globals per new session

-Original Message- From: Mark Kaye Thanks Danny. I've looked into this and it seems to be exactly what I'm looking for. You're a star. Hmm, it seems I can't use HttpSessionListener after all :(. After looking into it in more depth, it looks like I won't be able to get a handle

RE: [Core] Setup globals per new session

OK, I've decided to create an IndexAction and bind it to /index, then add welcome-fileindex.do/welcome-file to my web.xml. This appears to work and will allow me to set up all the session state I need dependant upon the hostname. I now have to figure out a clean mechanism to ensure that the

RE: [Core] Setup globals per new session

] Setup globals per new session OK, I've decided to create an IndexAction and bind it to /index, then add welcome-fileindex.do/welcome-file to my web.xml. This appears to work and will allow me to set up all the session state I need dependant upon the hostname. I now have to figure out a clean

RE: [Core] Setup globals per new session

Servlet spec for your app container. I hope this can at least get you started. Jason -Original Message- From: Mark Kaye [mailto:[EMAIL PROTECTED]] Sent: Friday, August 30, 2002 2:45 AM To: Struts Users Mailing List Subject: RE: [Core] Setup globals per new session -Original Message

Setup globals per new session

Hi, Please bear with me, I'm a Struts newbie :) I need to be able to detect and store some data based upon the request.getServerName() method result. i.e. When a user connects to my application (which will be listening on several different hostnames) I need to detect which host they are

RE: Setup globals per new session

2002 15:51 To: Struts Users Mailing List Subject: Setup globals per new session Hi, Please bear with me, I'm a Struts newbie :) I need to be able to detect and store some data based upon the request.getServerName() method result. i.e. When a user connects to my application (which

RE: Setup globals per new session

-Original Message- From: [EMAIL PROTECTED] You could have an index page that automatically redirects to a struts action. This action could retrieve the information you require and then decide which way to direct the user. I had thought of this option. But that wouldn't work if

RE: Setup globals per new session

:[EMAIL PROTECTED]] Sent: 29 August 2002 16:01 To: Struts Users Mailing List Subject: RE: Setup globals per new session -Original Message- From: [EMAIL PROTECTED] You could have an index page that automatically redirects to a struts action. This action could retrieve the information you

RE: Setup globals per new session

Implement the HttpSessionListener -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, August 29, 2002 7:56 AM To: [EMAIL PROTECTED] Subject: RE: Setup globals per new session Hello, You could have an index page that automatically redirects

RE:[Core] Setup globals per new session

-Original Message- From: Trieu, Danny [mailto:[EMAIL PROTECTED]] Implement the HttpSessionListener Thanks Danny. I've looked into this and it seems to be exactly what I'm looking for. You're a star. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional