Re: What is the best way to handle invalid values from a WOTextField?
Re: What is the best way to handle invalid values from a WOTextField?
- Subject: Re: What is the best way to handle invalid values from a WOTextField?
- From: Chuck Hill <email@hidden>
- Date: Wed, 16 Jul 2008 16:18:12 -0700
Hi David,
6081327
6081320
In addition to the really nasty 6078428 :-)
Thanks,
Chuck
On Jul 16, 2008, at 4:09 PM, David den Boer wrote:
How about bug reports with simple reductions, and I can have a look
at them ASAIC (as soon as I can)?
On Jul 16, 2008, at 4:00 PM, Chuck Hill wrote:
On Jul 16, 2008, at 10:19 AM, Guido Neitzer wrote:
On 16.07.2008, at 11:14, Chuck Hill wrote:
Did you try the "we are all happy citizens"-setting for encoding?
er.extensions.ERXApplication.DefaultEncoding=UTF-8
That helped for us, when we had problems with a file upload in
that form. There was also a bug in WO regarding comparison where
it did an == comparison instead of equals when comparing
encoding names. That should be fixed in nightly builds but
probably didn't make it to 5.4.2.
That did not fix it. The upload works fine on 5.3.3. I also get
the same problem if I take the upload off of the page! It really
seems to be the form settings. But I can't reproduce it in a
stand alone demo app.
That's interesting. I'm at a loss now. As I said: we saw similar
behaviour when we had the encoding not properly set up. Don't know
other cases.
Guido wins the prize!
A long time ago, for reasons that are no longer clear to us, we
added this code to our Session superclass:
/**
* Overridden to force request values to be UTF-8 encoded.
*/
public void takeValuesFromRequest(WORequest aRequest, WOContext
aContext)
{
aRequest
.setDefaultFormValueEncoding(_NSUtilities.UTF8StringEncoding);
super.takeValuesFromRequest(aRequest, aContext);
}
Now, session is probably not the best place to do this, but it
worked fine until 5.4.2. So, there are two fun parts to this:
1. _NSUtilities.UTF8StringEncoding is wrong:
public static final String UTF8StringEncoding = "UTF8";
That should be UTF-8. The code was changing UTF-8 to UTF8 and
that is what triggered the bug.
2. WORequest.setDefaultFormValueEncoding() discards any previously
parsed form values. Which is OK usually, but with a content-type
of multipart/form-data, it does not seem to be able to re-parse
them. So you silently end up with no form values.
I feel some bug reports coming on!
Chuck
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
David den Boer | Architect, IS&T Web Applications | email@hidden
| ( 408.974.9739
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden