Bear Bibeault wrote:Whether the control was built dynamically with JavaScript or not is moot. When the form is submitted, the state of the form at submission time is all that matters. You need to look at the request parameters that were submitted to know what state to recreate.
Bear Bibeault wrote:I see, but the answer is the same. You need to have JSP mechanisms on the page to recreate the state. For example, rather than letting the drop downs cascade, you'll need to fill them in when you know the values in advance.
Basically, test to see if you know a value, and if not, set up the page for initial display, if so, set up the page with the displays showing the values. It's likely to be a lot of <c:if>'s and <c:choose>'s on the page.
Bear Bibeault wrote:There is no way to do that automatically. Anything you dynamically built will be lost on refresh.
You either need to structure the app such that a refresh is not necessary, remember the state and restore it (in the JSP, in the script, or both), or just let it be.
Is there something about your workflow that requires a refresh before the user is done with the form?
Bear Bibeault wrote:You can see the examples in action at: http://bibeault.org/jqia2/
And the cascading dropdowns example at: http://bibeault.org/jqia2/chapter8/bootcloset/phase.3.html
Bear Bibeault wrote:Why XML in the response. Again, you taking the more difficult rome. JSON is much preferred as it is much easier to digest on the client side.
Or better yet, if the intent of the response is to provided dat to build the options list, build the options list in the response and just plunk it into the select.
I can point you to some example of doing this sort of thing in jQuery if you are interested.
Bear Bibeault wrote:
Axel Brown wrote:
Original JSP is loading all products (1000+) into the drop down so I decided to fix this with AJAX.
How is using Ajax going to "fix" this? What's broken? What's being "fixed"?
Originally posted by Ben Souther:
It's impossible to say what it could be without seeing the exceptions and the code that's causing them to be thrown.
Rather than trying to manipulate Tomcat into reporting less, I think it would be a better idea to track down what ever is throwing exceptions in your code and get those things fixed.
Originally posted by Ben Souther:
I don't think this has anything to do with Tomcat.
Have you verified that the same error is not being thrown repeatedly?
Originally posted by Joachim Rohde:
Hm... just a random guess:
Are you using Log4j (or is any framework that you are using, using Log4j)? I just remember that I setted the logging-level of a spring-application to 'debug' which generated tons of logging-output.