Wes Sorensen

+ Follow
since Dec 02, 2005
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Wes Sorensen

Perfect! Thank you Merrill & Jitender! I appreciate your help!
15 years ago
Thanks for the suggestions. I'll send it via GET instead. Probably a question that should be in the servlet forum, but quickly, is there a guideline on when GET should be used over POST (other than already discussed)? Sorry, probably a very basic servlet question...
15 years ago
Thanks Merrill. I was thinking that in a normal JSP -> JSP you might just send it as URL parameters and then a bookmark would work. I suppose it might still work OK like this in Struts, but I'm not positive.

I may have to continue to play with it some. I'm just trying to make it easy for my users to send links to another person and have it work. I guess if I sent it over using URL parameters...

ie: www.mycompany.com/showUserDetails.do?userid=15

or www.mycompany.com/searchResults.do?param=criteria
15 years ago
I appreciate the reply, and in many situations, bookmarking the action is fine. My question is, say you have a page with a search button on it. You type in your search criteria and the JSP goes to your action which build a bean of the results and then through an ActionForward sends to the JSP to display the results.

The bookmark will just be the search.do action, so bookmarking that page of results will not be helpful since the bean of results will not be there next time.

What's the solution?
15 years ago
Hello All,

As I've been working with Struts for a little while, I've noticed something. It's almost like working with frames sometimes. I can have a page, say a user details page. The request goes from a JSP to the action then to a details JSP. The URL is not unique for that user.

If a user wants to bookmark that page, the bookmark won't work the next time they use it.

Is there a way to make this work? Something I can change?

15 years ago
Hi All, I've decided to move my JSPs and related files under the WEB-INF directory. I've done this and setup Dreamweaver to work right. When I deploy my site, the images don't show up.

I'm wondering, should only the JSP files be under there or can all web files be under there?

I was planning to just have a index.html that automatically forwards to the Welcome.do page in the root of the webapp. Then have all JSPs, graphics, .js files, etc. under the WEB-INF/web directory.

It appears that I can't have the graphics files under there?

It's very important to me that my users not be able to call a JSP directly, therefore, I was going to come extreme measures to limit their ability to do so - lots of checking in every JSP that wouldn't need to be done if under the WEB-INF. I tried once before and ran into a roadblock - likely the same one. Anyone able to help?

Thanks so much!
16 years ago
Merrill's is a pretty good solution that will eliminate multiple database calls and would work well for a small site or a small rowset, but the scaling of it might be a factor.

Say you're doing this for eBay and someone does a search for "computer". This returns say 15,000 rows. This could be a serious memory and performance problem - atleast on the first request where it loads the bean.

I like the bean idea with the different fields, but I'd say take out the collection of rows, create a separate bean of the rows for that page - whatever the number of rows to display on the page is. So each request for the next page would result in a database query to load the bean, but it should be a small hit. This way, you don't max out your server memory after the 100 person does a query.

The advantages to Merrill's solution is that you can do a single database lookup, store the results and basically just refresh the page. If you're not concerned with the memory or you know certain pages will have a small rowset, you can use that solution. Otherwise, consider something that will scale well no matter how many rows get returned.
16 years ago
I've seen this done with javascript. Never done it myself, but seen the code to do it. From what I remember, you have two sets of arrays. One has the first drop down list, the other is an array of all the other items, keyed off the first.

Then you disable the second drop down until an option is picked from the first. You watch for a onChange() for the first drop down, then repopulate the second (and enable if disabled).

Probably not very clear, sorry. That's the general idea, though. You have to "load" all options into the page, then update with javascript.


BTW, cars.com does this, so you can look at the page source there to get some ideas.
16 years ago
Thanks A. Harry. I changed that setting as well. No change.

The fact that FF is working and that it doesn't work in IE on my local machine, I'm starting to think that my IE has a problem. I did some searching in the Tomcat forum and didn't find anything that would help me.

This is so odd, that I'm starting to think that IE has a problem. I can switch the cookie settings and nothing happens.

Thanks for the feedback, guys/gals.
16 years ago
Ok, what the heck! I just uploaded the files to my host, which runs Apache/Tomcat5 and it works great in both browsers.

As I said, I think this may have coincided with my upgrade to Tomcat5, but I can't say for sure.

Could this be a Tomcat config problem?
16 years ago
Well, after a couple hours of trying to figure this out, as long as IE has the jsessionid in the URL, all is good. If I delete the jsessionid from the URL, every click on menu items results in a new session.

This remains the same if all cookie settings are turned off (accept all cookies). I expected it to revert to cookie jsessionids, so removing from the URL wouldn't have mattered.

The puzzling thing is that Firefox works great, even with the removal of the jsessionid from the URL.

I'm still working on this, but it's getting VERY frustrating.
16 years ago
Thanks Marc. No, the whole site uses Struts. No direct access to JSP pages. Every request goes through an Action.

I subclassed Action 3 separate times for the types of access:

AdminAction, MemberAction, OpenAction

The Admin action would check to see if you are an admin (in this session variable) and then allow you to get to the actual action. The same for member (ie: logged in).

I will try what you suggest. I'm outputting several logging messages along the way (log4j) as well. I'll let you know what I find.
16 years ago
Hello All,

I've been working with Struts for a little while now and had built the beginnings of a site. My host is running TC 5, so I upgraded from TC 4 on my development machine. I don't know if my problems coincided with that move or not, but now I'm experiencing some weird behavior.

The site has some "secured" areas that are protected with form authentication. All my JSP URLs are URLEncoded() so they pass the jsessionId in each link. That works fine, and the session ID stays the same.

When a user logs in, the form gets passed to the LoginAction which authenicates the user from a database, then I set ActionForm and set it in a session Attribute:

The first page after the login, the jsessionid is gone from the URL and as soon as I go to another page, the session is "lost" to where the site doesn't think the user is logged in anymore (it's checking for that loginUser attribute).

I've done a bunch of searching here since this seems like the best Struts forum around, and it looks like it may be in my getSession(), where I should be passing the false parameter. I have other getSessions(), so I think I need to change those too, but figured I'd throw it out here first.

Marc often posts about the three things to do to not track sessions. I need to be able to use the session variable in my JSPs, so I can't go that route, but would it help to turn off the locale and maybe not use the <HTML:HTML> tag?

I need to go through my code and try a few things, but figured I'd throw it out here for comments.


16 years ago