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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
In reply to this post by Damien Pollet
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 <[hidden email]> 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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> 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 <[hidden email]> 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 > > > _______________________________________________ > SmallWiki, Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
On 04/11/2007, Lukas Renggli <[hidden email]> wrote:
> > 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. 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? > 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 _______________________________________________ SmallWiki, Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
> 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 |
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 <[hidden email]> wrote: > > 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 > -- 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 |
On 05/11/2007, Lex Spoon <[hidden email]> wrote:
> On Sunday 04 November 2007 18:25:07 Damien Pollet wrote: > > PS. Lex, can you update KomHttpServer and related in the universe? > > Sure, but can you be more precise? What update would you like? upgrade to the latest version from SqueakSource, it includes a bunch of fixes. > Alternatively, would you or someone you know like to maintain the Kom* entries > in the development universe? I could do it but I'm only doing web development on a hobby basis, so I'm not the best person to maintain the package... I asked Giovanni on IRC since he's the author of the most recent changes. -- 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 |
Free forum by Nabble | Edit this page |