4 Nov
2007
4 Nov
'07
4:59 p.m.
Hi,
I have two Pier images that give partial HTML an a particular page in
Pier. Safari just displays a few lines of uninterpreted, unfinished
HTML. The HTML ends repetedly at the same place:
- in one image it's in the middle of a string (html text: 'in the
middle of this string')
- in the second image it's just after the first occurence of a
continuation argument in a URL (this image is squeak-dev 7145 + latest
pier-blog from universes)
I tried debugging, but the HTML generation goes further than what
Safari gets, so the bug must be later when seaside sends the page to
the browser… any idea how to proceed ?
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
4 Nov
4 Nov
6:48 p.m.
Looks very strange. Can you provide additional information about the
package versions being used?
Is this Seaside 2.8? Do the interactive Seaside Tests pass? Do the
Magritte/Pier SUnit Tests pass?
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
6:49 p.m.
Seems the solution is:
WAKom stop.
WAKomEncoded startOn: 8080
So maybe all the Pier packages don't use the same UTF/WideStrings default ?
On 04/11/2007, Damien Pollet <damien.pollet(a)gmail.com> wrote:
Hi,
I have two Pier images that give partial HTML an a particular page in
Pier. Safari just displays a few lines of uninterpreted, unfinished
HTML. The HTML ends repetedly at the same place:
- in one image it's in the middle of a string (html text: 'in the
middle of this string')
- in the second image it's just after the first occurence of a
continuation argument in a URL (this image is squeak-dev 7145 + latest
pier-blog from universes)
I tried debugging, but the HTML generation goes further than what
Safari gets, so the bug must be later when seaside sends the page to
the browser… any idea how to proceed ?
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
7:16 p.m.
WAKom stop.
WAKomEncoded startOn: 8080
So maybe all the Pier packages don't use the same UTF/WideStrings
default ?
I am always using WAKom, this means the model will contain UTF-8
Strings only. If you use one of the other Kom servers your model will
contain strings with a different encoding.
Pier does not care how the strings are encoded in its model, it only
has to be consistent. Also some web servers have (well known) problems
when the encoding is incompatible.
Cheers,
Lukas
On 04/11/2007, Damien Pollet
<damien.pollet(a)gmail.com> wrote:
--
Lukas Renggli
http://www.lukas-renggli.ch
Hi,
I have two Pier images that give partial HTML an a particular page in
Pier. Safari just displays a few lines of uninterpreted, unfinished
HTML. The HTML ends repetedly at the same place:
- in one image it's in the middle of a string (html text: 'in the
middle of this string')
- in the second image it's just after the first occurence of a
continuation argument in a URL (this image is squeak-dev 7145 +
latest
pier-blog from universes)
I tried debugging, but the HTML generation goes further than what
Safari gets, so the bug must be later when seaside sends the page to
the browser… any idea how to proceed ?
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
8:15 p.m.
On 04/11/2007, Lukas Renggli <renggli(a)iam.unibe.ch> wrote:
Well, with WAKom (or whichever is automatically launched from the
universes package), it wasn't working. I had just created a pier-blog
with an ellipsis (… alt-semicolumn on a Mac qwerty) in its
description. After stopping WAKom and starting WaKomEncoded, I could
see the blog page. Since then I replaced the ellipsis with three
periods and I can see the page with WAKom too.
Still with WAKom, I can type accented characters in a blog entry and
pier will accept them but they display as "unknown characters" in
Safari and question marks in Firefox. If I type an ellipsis I get the
partial output (seems reliable).
Back in WAKomEncoded, if I type accented characters, I get an internal
server error, with either "subscript out of bounds", or "Invalid UTF-8
input" as an explanation, depending on which and haw many accented
characters I input. But wait, if I add an ellipsis with the accented
characters, all works perfectly!
/me scratches head
Note that in all cases the page is marked as UTF 8 in the xml header,
so I suppose Safari sends UTF 8 in the form? Do the WAKom* variants do
the recoding to whatever UTF or WideStrings they try to use
internally?
WAKom stop.
WAKomEncoded startOn: 8080
So maybe all the Pier packages don't use the same UTF/WideStrings
default ?
I am always using WAKom, this means the model will contain UTF-8
Strings only. If you use one of the other Kom servers your model will
contain strings with a different encoding. Pier does not care how the strings are encoded in its
model, it only
has to be consistent. Also some web servers have (well known) problems
when the encoding is incompatible.
I'm connecting directly to Squeak for the moment, no proxy or anything.
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
10:41 p.m.
Well, with WAKom (or whichever is automatically
launched from the
universes package), it wasn't working.
WAKom, I guess.
I had just created a pier-blog
with an ellipsis (… alt-semicolumn on a Mac qwerty) in its
description. After stopping WAKom and starting WaKomEncoded, I could
see the blog page. Since then I replaced the ellipsis with three
periods and I can see the page with WAKom too.
I guess Kom from Package Universe is not compatible with Seaside.
Update to the latest one from SqueakSource.
Note that in all cases the page is marked as UTF 8 in
the xml header,
so I suppose Safari sends UTF 8 in the form? Do the WAKom* variants do
the recoding to whatever UTF or WideStrings they try to use
internally?
UTF-8 is pretty standard in the web. Seaside uses it as a standard
declaration in its headers. This means that data the browsers expect
are UTF-8 and they also send UTF-8 back to the Server. Depending on
what WAKom adapter your are using the input is converted to Squeak
encoding or not.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
5 Nov
5 Nov
12:25 a.m.
OK. with the latest Kom, it seems to work nicely with both WAKoms.
it displayed garbage or failed gracefully (red validation message over
the editor in Pier) when I edited text that had been entered with the
other WAKom but that was predictible and OK.
PS. Lex, can you update KomHttpServer and related in the universe?
Thanks!
On 04/11/2007, Lukas Renggli <renggli(a)iam.unibe.ch> wrote:
--
Damien Pollet
type less, do more [ | ] http://typo.cdlm.fasmz.org
Well, with
WAKom (or whichever is automatically launched from the
universes package), it wasn't working.
WAKom, I guess.
I had just created a pier-blog
with an ellipsis (… alt-semicolumn on a Mac qwerty) in its
description. After stopping WAKom and starting WaKomEncoded, I could
see the blog page. Since then I replaced the ellipsis with three
periods and I can see the page with WAKom too.
I guess Kom from Package Universe is not compatible with Seaside.
Update to the latest one from SqueakSource.
Note that in all cases the page is marked as UTF
8 in the xml header,
so I suppose Safari sends UTF 8 in the form? Do the WAKom* variants do
the recoding to whatever UTF or WideStrings they try to use
internally?
UTF-8 is pretty standard in the web. Seaside uses it as a standard
declaration in its headers. This means that data the browsers expect
are UTF-8 and they also send UTF-8 back to the Server. Depending on
what WAKom adapter your are using the input is converted to Squeak
encoding or not.
Cheers,
Lukas
--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
SmallWiki, Magritte, Pier and Related Tools ...
https://www.iam.unibe.ch/mailman/listinfo/smallwiki
6270
days inactive
6270
days old
6 comments
2 participants
participants (2)
-
Damien Pollet -
Lukas Renggli