thanks for that mark and geeta. i'll run a test to make sure, I just wanted to confirm my gut feeling on the best way to proceed, which (thank you) you have done.
we've solved the problem of login by using a servlet filter, but after logon it forwards back to the page you came from. thanks simon -----Original Message----- From: Geeta Ramani [mailto:[EMAIL PROTECTED] Sent: 25 October 2003 20:53 To: Struts Users Mailing List Subject: Re: going straight to a jsp Simon: I think I agree with what Mark writes below. Especially if you consider that what is a "simple link" today may very well not be one tomorrow - if your clients are like the ones I work for..;) .. My gut feeling is that performance will not be a major factor since struts-config.xml is loaded once at startup, but by all means run a performance test to be sure.. Going back to your second question, if you have say an 'initial" page (like login.jsp) which you want people to always "start from", then one way of getting round the bookmarking issue would be to set a session variable after a user "gets in" (like authenticates). Then at the top of every jsp you could ensure that that session variable exists and is nonnull. If it doesn't exist then forward to the login.jsp. This will effectively solve your bookmarkig issue.. Regards, Geeta Mark Lowe wrote: > The performance costs are low, but using an action just to forward to > different views does have a very small performance cost. Run a stress > test and you'll see. > > The benefits however of doing everything via actions, far outweigh the > slight performance hit. You can start to think about your app in an > event based way. /save.do, /delete.do rather than the names of the > view's file name. > > Cheers Mark > > On Saturday, October 25, 2003, at 06:09 PM, Simon Matic Langford wrote: > > > it helps (a little). > > > > what i don't want is users bookmarking a jsp, which would then allow > > them to > > break MVC. however, isn't going via the forwardaction a little > > inefficent > > compared > > to linking direct to the jsp (my target environment is 2000 concurrent > > users)? or > > do you think the benefits of keeping to MVC might outweigh that? > > > > thanks for your help so far > > > > simon > > > > -----Original Message----- > > From: Geeta Ramani [mailto:[EMAIL PROTECTED] > > Sent: 25 October 2003 18:59 > > To: Struts Users Mailing List > > Subject: Re: going straight to a jsp > > > > > > Hi Simon: > > > > I think maybe you have misunderstood what it means to say "don't > > directly > > go to jsps". What this means is don't break the MVC pattern. So for > > example, if you have a link on your jsp and all you want it to do is > > to go > > to a second jsp, resist the temptation to code the second jsp directly > > using that as your href value. Instead respect the MVC design and use > > the > > fowardAction that Struts already has. This way you are always going > > to the > > controller (the ActionServlet) to find out where to go next. So, > > adding a > > "redirect=true" in your mappings is not a bad thing really (unless you > > want > > to preserve request attributes.. but that's another story..:) > > > > hth, > > Geeta > > > > Simon Matic Langford wrote: > > > >> Hi, > >> > >> I've been using struts for a couple of months now, and have been > >> working on the assumption that it is a bad thing to allow users > >> to go directly to jsp's. So I have ensured that I don't use > >> redirect="true" on forwards from an Action. > >> > >> Is this considered best practice for Struts? And are there any > >> concrete > >> reasons for or against this practice? > >> > >> Thanks > >> > >> Simon > >> > >> --------------------------------------------------------------------- > >> 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] > > > > > > --------------------------------------------------------------------- > > 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] --------------------------------------------------------------------- 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]
