[Seaside] 3.9 and encoding in multipart fields
Philippe Marschall
philippe.marschall at gmail.com
Thu Apr 26 22:42:53 UTC 2007
2007/4/27, Norbert Hartl <norbert at hartl.name>:
> On Thu, 2007-04-26 at 23:54 +0200, Philippe Marschall wrote:
> > 2007/4/26, Norbert Hartl <norbert at hartl.name>:
> > > On Thu, 2007-04-26 at 23:17 +0200, Philippe Marschall wrote:
> > > > 2007/4/26, Norbert Hartl <norbert at hartl.name>:
> > > > > .
> > > > > > Hmmm, it is still not working. I have two forms. One is only text fields
> > > > > > (multipart false) and one is text fields and input type="file"
> > > > > > (multipart true). I store the values in the database using Glorp.
> > > > > > I have two modifications to convert strings. One to utf8 when storing
> > > > > > in the database and one to convert from utf8 when reading from the
> > > > > > database.
> > > > > >
> > > > > > The multipart=false case leads to a proper store of the string in the
> > > > > > database. The multipart=true does not. Using WAKomEncoded39 the none
> > > > > > multipart case is displayed correctly. With WAKom the multipart case
> > > > > > is displayed correct.
> > > > > >
> > > > > > Examine the kom requests I can see that on multipart=false the strings
> > > > > > are displaying correct in the inspector. With multipart=true the
> > > > > > strings are looking strange (no conversion to the squeak encoding???)
> > > > > >
> > > > > > I don't know much about the multipart stuff. Are the single parts from
> > > > > > a multipart recognizable of which type they are (binary or text). I
> > > > > > would like to do a conversion if it is text. Do you have any hint where
> > > > > > in WAKom this encoding should occurr.
> > > > > >
> > > > > Ok, now I tested my theory. I added some code to WAKom to convert
> > > > > multipart fields to an internal representation.
> > > > >
> > > > > processMultipartFields: aRequest
> > > > > aRequest multipartFormFieldsDo:
> > > > > [:chunk |
> > > > > chunk explore.
> > > > > chunk fileName isEmptyOrNil ifFalse:
> > > > > [|stream file|
> > > > > stream := WriteStream on: String new.
> > > > > chunk saveToStream: stream.
> > > > > file := WAFile new
> > > > > fileName: chunk fileName;
> > > > > contents: stream contents;
> > > > > contentType: chunk contentType;
> > > > > yourself.
> > > > > aRequest postFields at: chunk fieldName put: file]
> > > > > ifTrue: [
> > > > > |stream|
> > > > > stream := WriteStream on: String new.
> > > > > chunk saveToStream: stream.
> > > > >
> > > > > aRequest postFields at: chunk fieldName put:( (stream contents)
> > > > > convertFromEncoding: #utf8)]
> > > > > ].
> > > >
> > > > Do I see correctly that the #ifTrue: part ist new?
> > > >
> > > yes.
> > > > > That works for me now. It is slower than any other approach while
> > > > > doing:
> > > > >
> > > > > - getting UTF-8 from the client (is that always true or how does WAKom
> > > > > decide?)
> > > >
> > > > WAKom does _nothing_ whatever the clients sends to you in whatever
> > > > encoding will be what you get.
> > > >
> > > Ok, that isn't very good. So I have to figure out the cases where I
> > > don't get utf-8 and cope with that.
> >
> > Then use the WAKomEncoded* series, they will deliver you WideStrings
> > and expect WideStrings for you (and use and expect utf8 externally,
> > you could make subclasses that do something else, it's just that
> > nobody ever needed anything besides utf8).
> >
> I can see WAKomEncoded39 is converting to utf-8 before sending the
> respose. WAKomEncoded does some conversion I don't understand. Under
> which circumstances is a field kind of OrderedCollection?
Pff, you ask me stuff (yes, comments would help) ;)
I know this method has my author initials but that just means I was
the last one who touched it and it was probably a formatting or
categorization issue.
> Using WAKom with 3.9 means you can easily lose control over strings.
And you will have internal server errors.
> As long as there is no conversion every part has to assume to deal
> with the same character encoding. But I doubt this is always easy to
> accomplish. As long as no conversion occurs there is no internal
> representation of the corresponding character. So string comparsion,
> regex and the like are rendered unusable. Or do I misunderstand this
> completly?
Yes, also substrings are broken, and #size, and checking for letters
and capitalization and whatever I forgot.
And you won't be able to use literals with non-ascii characters directly.
On a side note, who knows the difference between mysql_escape_string
and mysql_real_escape_string? ;)
> > BTW although some people actually say Seaside is the worst documented
> > piece of Smalltalk code they know all this stuff is covered in class
> > comments. Which just proves that writing comments is pointless because
> > nobody reads them anyway ;)
> >
>
> One point is if there is documentation another one is to find it ;)
> Which documentation do mean?
Class comment in WAKomEncoded. No I was just joking. ;)
Cheers
Philippe
> Norbert
>
>
>
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
More information about the seaside
mailing list