That's an interesting thought Craig... I actually was very much aware of that behavior, having been burnt in the past... A lot of my GUI design does in fact disable elements because it's hard to get disabled elements to look exactly like Windows elements do when disabled by just manipulating read-only. My code does take this into account, but it's possible the users are doing some really unexpected thnigs and thereby breaking my code (because, of course, the code isn't ingerently broke! :) ). I considered this possibility a while ago and all but dismissed it, now I think I may go re-visit it a bit...
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com On Fri, October 22, 2004 3:30 pm, Craig McClanahan said: > I don't know if this is happening to you, but one thing to examine > your client side JavaScript code for is setting an input element's > "disabled" property. If you ever do this, and then submit the form > that contains that element, the browser will *not* include the element > with the request. In turn, this would have the effect of not setting > that property in your form bean, leading to the types of symptoms you > are observing. > > If your UI wants to selectively disable the ability of the user to > change an input field, you should manipulate the "readonly" property > instead. That's because readonly input elements are still included. > > Craig > > > On Fri, 22 Oct 2004 12:10:42 -0700 (PDT), [EMAIL PROTECTED] > <[EMAIL PROTECTED]> wrote: >> Hello all... I've got a strange situation that's been bugging me for a >> while. First, some quick background: >> >> I wrote an application about two years ago that was based on a >> proprietary framework that has now been converted to Struts. One of the >> things this proprietary framework was missing was the concept of >> ActionForms. Instead, when you hit your controller classes, you dealt >> with the Request object directly to get your parameters. >> >> Since as usual I had to get the conversion done in far less time than it >> should have been done in, I basically would up not really using >> ActionForms except to transfer data back to the view. In other words, >> no validation is don in the ActionForms, and they are not >> auto-populateed by Struts. My Actions still deal directly with Request, >> I just populate the ActionForm on the way out to the JSP (I intended to >> use the ActionForms more "properly" later, but that time has never >> presented itself). >> >> So, now I come to the issue... It seems that every now and again >> (average of about 25 times per 50,000 transaction) I get NPE's in my >> Actions and they are always because some value that was expected to be >> in Request is null. >> >> Now, the front-end does a bunch of validation (JavaScript) and I've gone >> over it a ton of times and there doesn't seem to be any way a user could >> submit a form without filling in required elements (and most of them >> should be blanks anyway, not nulls). I thought about maybe they were >> using the Back button in some crazy way, but the app opens in a new >> chromless window, so they would have to be using a keyboard shortcut. >> I've tried every crazy thing I could think of to break it, but it never >> seems to break. I have NEVER ONCE replicated one of these problems. >> >> So, my question comes down to this... has anyone ever seen a situation >> where a Struts-based app running on Tomcat (5.0.25 I believe) would >> "lose" request data, either as a fault of Struts or of Tomcat? Could it >> be some Tomcat tuning issue? (I will ask this same question on the >> Tomcat list, but I wanted to start here first). >> >> Any thoughts would be appreciated. Fortunately no one is complaining >> because the app is generally quite stable, but these once-in-a-while >> exceptions are pissing me off more than anything else! >> >> >> --------------------------------------------------------------------- >> 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]
