[Seaside] 3.9 and encoding in multipart fields

[Norbert Hartl]

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? 
Using WAKom with 3.9 means you can easily lose control over strings.
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?

> 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?

Norbert