Originally posted by Nina Anderson:
1. "placeOfBusinessList" is already an ArrayList property of the PackageForm. Is that what you mean?
Ok, I see what you mean. I didn't see the bean:define tag earlier. Yes, the placeOfBusinessList is what I mean.
Originally posted by Nina Anderson:
2. I'm using "redirect=true" for the validation. I'm new to Struts, so I'm wonder where I need to implement the "super.validate(...)" method.
Whether you use redirect="true" is unimportant. What is important is whether you're using the Struts Validation Framework or just writing your own validation logic in the ActionForm's validate method. If you don't know what the validation framework is, then you're obviously not using it, so you can ignore what I said about calling super.validate(...). You only need to make that call if you're using the Validation Framework.
Originally posted by Nina Anderson:
you mention that I'll need to repopulate the list from db. So, I'm wondering...Will I need to re-query the database again to get this list? That doesn't seem like an efficient route.
Realistically, you have only three choices here:
1 - You can store the list of options or the ActionForm in the session.
2 - You can pass the values via hidden fields in the JSP.
3 - You can re-query the database to get the list.
Option 1 I dimissed because you already said you're against storing anything in the HTTPSession (Which I disagree with, but that's another discussion).
Option 2 is in my view way more trouble to implement than it's worth, especially if you have a list of JavaBeans. You'd have to write a lot of code for this, and you wouldn't really get much in return.
That leaves us with option 3. I can understand why it might appear to be inefficient. After all, you already got these values once... why do all those disk reads just to get them again?
In actuality, it's likely this option will not cause any additional disk reads at all. Every enterprise relational database worth having has a caching mechanism. That means that if you read the same data again a second time, the chances are pretty good that the RDB is retrieving it from its memory cache rather than from disk.
If you implement this solution, I doubt you'll see any perceivable difference in performance, even with a large number of concurrent users.
[ October 09, 2007: Message edited by: Merrill Higginson ]