Frank, Although your solution would work I'd be apprehensive about any solution which involves doing anything manually at the start of each action. I'd suggest that anything that needs to happen for each & every action is better suited to a modified RequestProcessor, or a Filter.
As you want to deal with all requests - not just actions, I'd suggest that a Filter would be the way to go. My apologies if I'm trying to teach you to suck eggs :-) Paul > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 23 December 2004 14:41 > To: user@struts.apache.org > Subject: RE: Accessing my form from an included page > > > On Thu, December 23, 2004 9:13 am, Donie Kelly said: > > [Donie Kelly] Hi Guys > > > > OK, I ran through most of what your are telling me and must > first thank > > you > > all for the detailed responses. > > You spawned an interesting thread! The seemingly simple > questions are usually the ones that do that though. :) > > > 1) I want to check I have a valid session so that I know > the objects I > > have > > been carrying through the session are still there. It they > are not, I want > > to reestablish them by redirecting back to some starting page which > > initialises the session. > > I can tell you the way I've done this in the past... Firstly, > note that the best way is with some plug-in to your web > server (or app server) that externalizes security, something > like Netegrity for example. This would handle expiring > sessions and such as you want, redirecting to some logon page > presumably. > > In the absence of that though, what I've done is to have an > ActionHelpers class... This class contains two methods, > start() and finish(). start() is called at the start of each > Action and finish(), you guessed it, is called right before > returning the ActionForward. > > Let's ignore what finish() does because it's not applicable > here... start() however is... The first thing it does is > calls checkSession() (my own method) that verifies if the > session is valid or not, and redirects to the logon page if it's not. > > That takes care of one piece of the puzzle... the other is > what happens if someone accesses a JSP directly? All I do > here is call checkSession() directly. If it's invalid, the > page renders a redirect. So, all the JSP's have a structure > along these lines: > > <% if (!ActionHelpers.checkSession()) { %> > <HTML><HEAD><TITLE></TITLE> > <META HTTP-EQUIV="refresh" > CONTENT="0;URL=http://www.mysite.com/logon.do";> > </HEAD><BODY</BODY></HTML> > <% } else { %> > ... The actual page goes here > <% } %> > > That does the trick. I'm in NO WAY saying this is > industrial-strength security, but it gets the job done. In > the environment I do this in, security isn't an issue though, > so this is fine. Also, it wouldn't be trivial I think to > hack this anyway since you have to get a valid session on the > server at some point that matches what's on the client, and > assuming that can only be done through some logon procedure, > it should be not completely insecure :) > > > 2) Need to put page navigation in the header.jsp page to > make it easy to > > navigate. I guess I will be putting stuff in the session to > make so I was > > going to use the form to return the breadcrumb name. Is > this a good way to > > do it? > > I would suggest looking for a canned breadcrumb solution. > There was a recent thread about just that, and some existing > solutions were mentioned. > > If your going to build your own, you need to determine what > information you really need to construct your nav bar. I > doesn't sound like you need access to the Form Bean, as I had > thought you were asking originally (maybe you were, maybe I > misunderstood... doesn't really matter I guess :) ). Sounds > like what you really need is the Action path for all the > pages that have been visited in order. > > I would myself be thinking of a linked list structure, stored > in session, with each item holding the mapping path. That > should be all you need to construct a breakcrumb path. > > But again, no sense reinventing the wheel... Solutions for > this exist already. > > > That's it really. > > Donie > > > > -- > > No virus found in this outgoing message. > > Checked by AVG Anti-Virus. > > Version: 7.0.296 / Virus Database: 265.6.4 - Release Date: > 22/12/2004 > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > Axios Email Confidentiality Footer Privileged/Confidential Information may be contained in this message. If you are not the addressee indicated in this message (or responsible for delivery of the message to such person), you may not copy or deliver this message to anyone. In such case, you should destroy this message, and notify us immediately. If you or your employer does not consent to Internet email messages of this kind, please advise us immediately. Opinions, conclusions and other information expressed in this message are not given or endorsed by my Company or employer unless otherwise indicated by an authorised representative independent of this message. WARNING: While Axios Systems Ltd takes steps to prevent computer viruses from being transmitted via electronic mail attachments we cannot guarantee that attachments do not contain computer virus code. You are therefore strongly advised to undertake anti virus checks prior to accessing the attachment to this electronic mail. Axios Systems Ltd grants no warranties regarding performance use or quality of any attachment and undertakes no liability for loss or damage howsoever caused. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
