AIDASite class>>isOldEncoding:

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

AIDASite class>>isOldEncoding:

Stefan Schmiedl
A few hours ago, I wrote

> I spent a few hours on my project today, and all I can say is that
> AIDASite class>>isOldEncoding: is *evil* if you feed it German text.
> More on this in a separate post later.

After I managed to find my way around the EXDI for ODBC, I had a list
of employees on my hands, which should be displayed in a table. So I
follow the approach of the tutorial. The list comes up on the first
try. Good.

But there is a slight cosmetic problem, the name "G?nter" is displayed
as "G?nter" with the special glyph that firefox uses for encoding
problems.

As an additional data point I added a WebText "?berstunden" (overtime)
which was printed correctly. Then I started to look at how VW/ODBC
handle different encodings. Then I noticed that "J?rg" was actually
printed as "J?rg"... what's happening here?

Good thing that the debugger can single step ... but even so it took me
a while to locate the culprit. isOldEncoding compares the character
codes against some values, of which $? = 16r00FC is one, but $? is not.
So "J?rg" is not considered "old encoding" and correctly converted,
while "G?nter" is, hence is not.



Another minor hurdle is that in AIDA 5.2.2 from the VW store the demo
site registers itself for localhost, 127.0.0.1 port 80 and
stays there. While this site is registered, calls to
AIDASite class>>newNamed: fail, since those are the default settings
used there and only one site per host is allowed.



Also I was a little bit stumped, when I added sorter buttons to my
table and was sent to the login page after clicking on them. You see, I
have taken the shortcut of allowing Guest access to the page I built,
but Guest has only read access, obviously by design. And it seems that
if Guest dares to try and change something (by clicking on a button),
he gets promptly punished by being sent out the door :-)

Logging in as admin, the buttons work as expected.



All things considered, the afternoon was well spent, and I'm looking
forward to the next time slice available for AIDA coding.

s.

Reply | Threaded
Open this post in threaded view
|

AIDASite class>>isOldEncoding:

Janko Mivšek
Hi Stefan,

Stefan Schmiedl wrote:
  >> I spent a few hours on my project today, and all I can say is that
>> AIDASite class>>isOldEncoding: is *evil* if you feed it German text.
>> More on this in a separate post later.
>
> After I managed to find my way around the EXDI for ODBC, I had a list
> of employees on my hands, which should be displayed in a table. So I
> follow the approach of the tutorial. The list comes up on the first
> try. Good.

And you probably already take care that you convert to pure Unicode from
your database into Smalltalk objects?


> But there is a slight cosmetic problem, the name "G?nter" is displayed
> as "G?nter" with the special glyph that firefox uses for encoding
> problems.
>
> As an additional data point I added a WebText "?berstunden" (overtime)
> which was printed correctly. Then I started to look at how VW/ODBC
> handle different encodings. Then I noticed that "J?rg" was actually
> printed as "J?rg"... what's happening here?
>
> Good thing that the debugger can single step ... but even so it took me
> a while to locate the culprit. isOldEncoding compares the character
> codes against some values, of which $? = 16r00FC is one, but $? is not.
> So "J?rg" is not considered "old encoding" and correctly converted,
> while "G?nter" is, hence is not.

AIDASite class>>isOldEncoding is a real relic from the past, back to 10
years ago in times of VW 2.5, which has some Xerox 16bit encoding instead
of Unicode. With VW 3.0 an Unicode was introduced and a real mess
begins. That method was meant to ease mess a bit ..

Solution:

Just delete first line in method
AIDASite class>>convert:toCodepage:

(self inOldEncoding: aString) ifTrue: [^self oldconvert: aString
toCodepage: aSymbol].

I already did and also removed all those "old" methods. That will show
up in a next release of Aida.

Best regards
Janko


--
Janko Miv?ek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si

Reply | Threaded
Open this post in threaded view
|

AIDASite class>>isOldEncoding:

Stefan Schmiedl
On Fri, 01 Jun 2007 11:26:09 +0200
Janko Miv?ek <janko.mivsek at eranova.si> wrote:

> Hi Stefan,
>
> Stefan Schmiedl wrote:
>   >> I spent a few hours on my project today, and all I can say is
>   >> that
> >> AIDASite class>>isOldEncoding: is *evil* if you feed it German
> >> text. More on this in a separate post later.
> >
> > After I managed to find my way around the EXDI for ODBC, I had a
> > list of employees on my hands, which should be displayed in a
> > table. So I follow the approach of the tutorial. The list comes up
> > on the first try. Good.
>
> And you probably already take care that you convert to pure Unicode
> from your database into Smalltalk objects?

Actually, no :-)

During debugging I saw that I get the usual windows encoding from the
database, 1250 or 1252 or whatever it is for western europe.

> Solution:
>
> Just delete first line in method
> AIDASite class>>convert:toCodepage:
>
> (self inOldEncoding: aString) ifTrue: [^self oldconvert: aString
> toCodepage: aSymbol].

did so already, display worked fine after that :-)

s.