AIDASite class>>isOldEncoding:

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.

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?


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

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

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.