stylesheet rendering problem on seaside 3.0
Locked
 
|
On the pier seaside 3.0 code-branch, browsing to: http://localhost:8080/pier/environment/style.css, results in: #[47 42 32 98 108 117 101 112 114 105 110 ...
rather than: /* blueprint patches */ h1, h2, h3, h4, h5, h6 { margin: 0; fo.... This issue is caused by a change in how ByteArray is rendered in Seaside 3.0 (the problem was also present prior to merging the latest Pier code):
seaside 2.8 Object>>encodeOn: aDocument aDocument print: self displayStriong seaside 3.0 Object>>encodeOn: aDocument aDocument print: self greaseString
ByteArray>>greaseString "ByteArrays should not automatically be converted to Strings. You should use a GRCodec for this."
^ self printString changing ByteArray>>greaseString to return self displayString fixes the problem. However I can see there are a number of ways to fix this, and as it's such a low level change I'm sure there was a good reason for displayString to be changed to printString. Thoughts?
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: stylesheet rendering problem on seaside 3.0
|
Maybe we need to implement #encodeOn: on ByteArray? Lukas?
Julian On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager <[hidden email]> wrote: > On the pier seaside 3.0 code-branch, browsing > to: http://localhost:8080/pier/environment/style.css, results in: > #[47 42 32 98 108 117 101 112 114 105 110 ... > rather than: > /* blueprint patches */ > h1, h2, h3, h4, h5, h6 { margin: 0; fo.... > This issue is caused by a change in how ByteArray is rendered in Seaside 3.0 > (the problem was also present prior to merging the latest Pier code): > seaside 2.8 > Object>>encodeOn: aDocument > aDocument print: self displayStriong > seaside 3.0 > Object>>encodeOn: aDocument > aDocument print: self greaseString > ByteArray>>greaseString > "ByteArrays should not automatically be converted to Strings. You should use > a GRCodec for this." > ^ self printString > changing ByteArray>>greaseString to return self displayString fixes the > problem. However I can see there are a number of ways to fix this, and as > it's such a low level change I'm sure there was a good reason for > displayString to be changed to printString. Thoughts? > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: stylesheet rendering problem on seaside 3.0
|
|
Has this been fixed, because it works here?
Lukas 2010/1/11 Julian Fitzell <[hidden email]>: > Maybe we need to implement #encodeOn: on ByteArray? Lukas? > > Julian > > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager <[hidden email]> wrote: >> On the pier seaside 3.0 code-branch, browsing >> to: http://localhost:8080/pier/environment/style.css, results in: >> #[47 42 32 98 108 117 101 112 114 105 110 ... >> rather than: >> /* blueprint patches */ >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >> This issue is caused by a change in how ByteArray is rendered in Seaside 3.0 >> (the problem was also present prior to merging the latest Pier code): >> seaside 2.8 >> Object>>encodeOn: aDocument >> aDocument print: self displayStriong >> seaside 3.0 >> Object>>encodeOn: aDocument >> aDocument print: self greaseString >> ByteArray>>greaseString >> "ByteArrays should not automatically be converted to Strings. You should use >> a GRCodec for this." >> ^ self printString >> changing ByteArray>>greaseString to return self displayString fixes the >> problem. However I can see there are a number of ways to fix this, and as >> it's such a low level change I'm sure there was a good reason for >> displayString to be changed to printString. Thoughts? >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Still not working in my image - I thought I'd downloaded the latest seaside3.0 source today, so that's a little odd. ... unless something has changed in Pharo. I'm using Pharo09.12. Does your the implementation of ByteArray>>greaseString match this:
ByteArray>>greaseString "ByteArrays should not automatically be converted to Strings. You should use a GRCodec for this."
^ self printString or does your image have an implementation of ByteArray>>encodeOn? 2010/1/11 Lukas Renggli <[hidden email]> Has this been fixed, because it works here? _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: stylesheet rendering problem on seaside 3.0
|
|
> Does your the implementation of
> ByteArray>>greaseString match this: > ByteArray>>greaseString > "ByteArrays should not automatically be converted to Strings. You should use > a GRCodec for this." > ^ self printString Yes. > or does your image have an implementation of ByteArray>>encodeOn? No. Maybe you should clear your browser caches? Lukas > 2010/1/11 Lukas Renggli <[hidden email]> >> >> Has this been fixed, because it works here? >> >> Lukas >> >> 2010/1/11 Julian Fitzell <[hidden email]>: >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >> > >> > Julian >> > >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager <[hidden email]> wrote: >> >> On the pier seaside 3.0 code-branch, browsing >> >> to: http://localhost:8080/pier/environment/style.css, results in: >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... >> >> rather than: >> >> /* blueprint patches */ >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >> >> This issue is caused by a change in how ByteArray is rendered in >> >> Seaside 3.0 >> >> (the problem was also present prior to merging the latest Pier code): >> >> seaside 2.8 >> >> Object>>encodeOn: aDocument >> >> aDocument print: self displayStriong >> >> seaside 3.0 >> >> Object>>encodeOn: aDocument >> >> aDocument print: self greaseString >> >> ByteArray>>greaseString >> >> "ByteArrays should not automatically be converted to Strings. You >> >> should use >> >> a GRCodec for this." >> >> ^ self printString >> >> changing ByteArray>>greaseString to return self displayString fixes the >> >> problem. However I can see there are a number of ways to fix this, and >> >> as >> >> it's such a low level change I'm sure there was a good reason for >> >> displayString to be changed to printString. Thoughts? >> >> >> >> _______________________________________________ >> >> Magritte, Pier and Related Tools ... >> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> > >> > _______________________________________________ >> > Magritte, Pier and Related Tools ... >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Hi Lukas,
Don't think the browse cache is the problem. What do you get with: #[100 101 98 117 103 103 105 110 103] greaseString on my image the result:
'#[100 101 98 117 103 103 105 110 103]'
2010/1/12 Lukas Renggli <[hidden email]>
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: stylesheet rendering problem on seaside 3.0
|
|
#[100 101 98 117 103 103 105 110 103], but this method is never called
when I browse Pier. Lukas 2010/1/12 Nick Ager <[hidden email]>: > Hi Lukas, > Don't think the browse cache is the problem. What do you get with: > #[100 101 98 117 103 103 105 110 103] greaseString > on my image the result: > '#[100 101 98 117 103 103 105 110 103]' > > 2010/1/12 Lukas Renggli <[hidden email]> >> >> > Does your the implementation of >> > ByteArray>>greaseString match this: >> > ByteArray>>greaseString >> > "ByteArrays should not automatically be converted to Strings. You should >> > use >> > a GRCodec for this." >> > ^ self printString >> >> Yes. >> >> > or does your image have an implementation of ByteArray>>encodeOn? >> >> No. >> >> Maybe you should clear your browser caches? >> >> Lukas >> >> > 2010/1/11 Lukas Renggli <[hidden email]> >> >> >> >> Has this been fixed, because it works here? >> >> >> >> Lukas >> >> >> >> 2010/1/11 Julian Fitzell <[hidden email]>: >> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >> >> > >> >> > Julian >> >> > >> >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager <[hidden email]> >> >> > wrote: >> >> >> On the pier seaside 3.0 code-branch, browsing >> >> >> to: http://localhost:8080/pier/environment/style.css, results in: >> >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... >> >> >> rather than: >> >> >> /* blueprint patches */ >> >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >> >> >> This issue is caused by a change in how ByteArray is rendered in >> >> >> Seaside 3.0 >> >> >> (the problem was also present prior to merging the latest Pier >> >> >> code): >> >> >> seaside 2.8 >> >> >> Object>>encodeOn: aDocument >> >> >> aDocument print: self displayStriong >> >> >> seaside 3.0 >> >> >> Object>>encodeOn: aDocument >> >> >> aDocument print: self greaseString >> >> >> ByteArray>>greaseString >> >> >> "ByteArrays should not automatically be converted to Strings. You >> >> >> should use >> >> >> a GRCodec for this." >> >> >> ^ self printString >> >> >> changing ByteArray>>greaseString to return self displayString fixes >> >> >> the >> >> >> problem. However I can see there are a number of ways to fix this, >> >> >> and >> >> >> as >> >> >> it's such a low level change I'm sure there was a good reason for >> >> >> displayString to be changed to printString. Thoughts? >> >> >> >> >> >> _______________________________________________ >> >> >> Magritte, Pier and Related Tools ... >> >> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> >> >> > >> >> > _______________________________________________ >> >> > Magritte, Pier and Related Tools ... >> >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> > >> >> >> >> >> >> >> >> -- >> >> Lukas Renggli >> >> http://www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> Magritte, Pier and Related Tools ... >> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > >> > >> > _______________________________________________ >> > Magritte, Pier and Related Tools ... >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > >> >> >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki > > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
Hello and Happy New Year to the list.
Thank you Julian, Nick, and Lukas for the port to Seaside 3.0. I'd like to give a hand to finalize this port, and started by "Pier-Setup" as follows: - Dependencies (in addition to the core Pier packages): Pier-Blog, Pier-Documents, Pier-Google, and Pier-Book. - Starting point: http://hudson.lukas-renggli.ch/job/Seaside%203.0/. - Loaded from http://source.lukas-renggli.ch/pier2: Pier-Blog-NickAger.135 and Pier-Documents-NickAger.17. - Loaded from http://source.lukas-renggli.ch/pieraddons: Pier-Google-lr.16, Pier-Book-lr.112, Pier-Setup-lr.71. Had just to edit one method (please see the attached file). - Executed "PRLoader setupPier" - Pointed to http://localhost:8080/pier. As far as I could test, it just works fine, including Gadgets. - Loaded Pier-Design-lr.8 to have the "Edit Design" command. It works, except for the stylesheet rendering issue already reported by Nick. Questions: 1) Would it make sense to isolate PRBookDistribution in a separate package, to avoid the current dependency between Pier-Setup & Pier-Book? 2) Would it make sense to have a PierBasicDistribution, without dependencies to Pier-Blog, Pier-Documents, Pier-Google? (PierDistribution could obviously then be a subclass of PierBasicDistribution). 3) Should I upload the above packages? 3.b) If yes, in which repository: http://source.lukas-renggli.ch/pier2 or http://source.lukas-renggli.ch/pier2-addon? For the moment all core and addon packages are in the same repository, which is somehow more practical compared to Pier 1. Remaining issues: A) Load scripts in PRLoader need to by adapted to the new repositories. B) Testing PREventDistribution and PRBookDistribution. I'm going to take care of (B). Cheers, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
rra_2010_01_12.a.st (1K) |
|
> I'd like to give a hand to finalize this port, and started by "Pier-Setup"
> as follows: As the commit comment says "Pier-Setup" is broken. I do not suggest to use it at the moment. Doru said that he is going to look at it. > 1) Would it make sense to isolate PRBookDistribution in a separate package, > to avoid the current dependency between Pier-Setup & Pier-Book? Pier-Setup is used to build the one-click images. It is not really ment to be used as an end-user tool. > 2) Would it make sense to have a PierBasicDistribution, without dependencies > to Pier-Blog, Pier-Documents, Pier-Google? (PierDistribution could obviously > then be a subclass of PierBasicDistribution). I would prefer to avoid too many extra packages. > A) Load scripts in PRLoader need to by adapted to the new repositories. > B) Testing PREventDistribution and PRBookDistribution. These two are broken in Pier 1. If you have a look at that could you first fix them for Pier 1? Lukas -- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
At 13:25 12/01/2010, Lukas Renggli wrote:
>Pier-Setup is used to build the one-click images. It is not really >ment to be used as an end-user tool. I understand, but I find it particularly useful also for setting rapidly an environment for testing ideas in the context, etc. >These two are broken in Pier 1. If you have a look at that could you >first fix them for Pier 1? Sure. I'm going to look at that. Later, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Pier-Setup change report (Pier 1 & 2)
|
|
In reply to this post by Lukas Renggli
Pier 1:
---------- I uploaded a new package "Pier-Setup-razavi_acm_org.72" to: For modification details, please see the package comments. Pier 2: --------- I loaded the same package into the Pier 2 image that I mentioned in a previous email this morning. All of the three distributions seem working fine. However, I had to hack the code in one method as follows (added calls to #asString and #asByteString]): GRPharoUtf8CodecStream >> nextPutAll: aString An open (Seaside 3.0 ??) issue: ---------------------------------------------- When hot switching distributions via the Design Chooser interface in the Home page, the following call sequences raises an exception: WAApplication (WARegistry) >> urlFor:ifAbsent: WAApplication (WARequestHandler) >> url WADispatcher >> urlFor: WADispatcher >> nameOfHandler: However, by forcing the navigator to point to http://localhost:8080/pier, the new distribution is launched and seems fully operational. Cheers, Reza _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
Re: stylesheet rendering problem on seaside 3.0
|
|
In reply to this post by Lukas Renggli
I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet.
Julian On Tue, Jan 12, 2010 at 2:59 AM, Lukas Renggli <[hidden email]> wrote: > #[100 101 98 117 103 103 105 110 103], but this method is never called > when I browse Pier. > > Lukas > > > 2010/1/12 Nick Ager <[hidden email]>: >> Hi Lukas, >> Don't think the browse cache is the problem. What do you get with: >> #[100 101 98 117 103 103 105 110 103] greaseString >> on my image the result: >> '#[100 101 98 117 103 103 105 110 103]' >> >> 2010/1/12 Lukas Renggli <[hidden email]> >>> >>> > Does your the implementation of >>> > ByteArray>>greaseString match this: >>> > ByteArray>>greaseString >>> > "ByteArrays should not automatically be converted to Strings. You should >>> > use >>> > a GRCodec for this." >>> > ^ self printString >>> >>> Yes. >>> >>> > or does your image have an implementation of ByteArray>>encodeOn? >>> >>> No. >>> >>> Maybe you should clear your browser caches? >>> >>> Lukas >>> >>> > 2010/1/11 Lukas Renggli <[hidden email]> >>> >> >>> >> Has this been fixed, because it works here? >>> >> >>> >> Lukas >>> >> >>> >> 2010/1/11 Julian Fitzell <[hidden email]>: >>> >> > Maybe we need to implement #encodeOn: on ByteArray? Lukas? >>> >> > >>> >> > Julian >>> >> > >>> >> > On Mon, Jan 11, 2010 at 4:40 AM, Nick Ager <[hidden email]> >>> >> > wrote: >>> >> >> On the pier seaside 3.0 code-branch, browsing >>> >> >> to: http://localhost:8080/pier/environment/style.css, results in: >>> >> >> #[47 42 32 98 108 117 101 112 114 105 110 ... >>> >> >> rather than: >>> >> >> /* blueprint patches */ >>> >> >> h1, h2, h3, h4, h5, h6 { margin: 0; fo.... >>> >> >> This issue is caused by a change in how ByteArray is rendered in >>> >> >> Seaside 3.0 >>> >> >> (the problem was also present prior to merging the latest Pier >>> >> >> code): >>> >> >> seaside 2.8 >>> >> >> Object>>encodeOn: aDocument >>> >> >> aDocument print: self displayStriong >>> >> >> seaside 3.0 >>> >> >> Object>>encodeOn: aDocument >>> >> >> aDocument print: self greaseString >>> >> >> ByteArray>>greaseString >>> >> >> "ByteArrays should not automatically be converted to Strings. You >>> >> >> should use >>> >> >> a GRCodec for this." >>> >> >> ^ self printString >>> >> >> changing ByteArray>>greaseString to return self displayString fixes >>> >> >> the >>> >> >> problem. However I can see there are a number of ways to fix this, >>> >> >> and >>> >> >> as >>> >> >> it's such a low level change I'm sure there was a good reason for >>> >> >> displayString to be changed to printString. Thoughts? >>> >> >> >>> >> >> _______________________________________________ >>> >> >> Magritte, Pier and Related Tools ... >>> >> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> >> >>> >> > >>> >> > _______________________________________________ >>> >> > Magritte, Pier and Related Tools ... >>> >> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> >> > >>> >> >>> >> >>> >> >>> >> -- >>> >> Lukas Renggli >>> >> http://www.lukas-renggli.ch >>> >> >>> >> _______________________________________________ >>> >> Magritte, Pier and Related Tools ... >>> >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> > >>> > >>> > _______________________________________________ >>> > Magritte, Pier and Related Tools ... >>> > https://www.iam.unibe.ch/mailman/listinfo/smallwiki >>> > >>> >>> >>> >>> -- >>> Lukas Renggli >>> http://www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Magritte, Pier and Related Tools ... >>> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> >> >> _______________________________________________ >> Magritte, Pier and Related Tools ... >> https://www.iam.unibe.ch/mailman/listinfo/smallwiki >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Magritte, Pier and Related Tools ... > https://www.iam.unibe.ch/mailman/listinfo/smallwiki > _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
I've tried to encapsulate the problem in a test: | stylesheetFile stylesheetContents rendererResult | stylesheetContents := '/* a style sheet */'.
stylesheetFile := (PRFile named: 'defaultCss') filename: 'style.css'; mimetype: 'text/css'; contents: stylesheetContents.
rendererResult := WARenderCanvas builder render: [ :html | html render: stylesheetFile file contents]. self assert: rendererResult = stylesheetContents
In my image the assertion fails. If I change ByteArray>>greaseString to return self displayString the assertion succeeds. Does that help?
2010/1/12 Julian Fitzell <[hidden email]> I'm seeing the same as Nick, fwiw. Same if I try to edit the stylesheet. _______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
I wonder if we've made it clear that stylesheet renders fine as a style sheet, it's only when you use Pier to view the stylesheet 'file' is the result is something like '[47 42 32 98 108 117 101 112 114 105 110 ..'
Anyway hopefully the test above encapsulates the problem.
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
|
|
In reply to this post by Reza Razavi
I've added Pier-Setup to the pier2 repository, allowing me to commit a change to the package which fixes the bug Reza reported below:
_______________________________________________ Magritte, Pier and Related Tools ... https://www.iam.unibe.ch/mailman/listinfo/smallwiki |
«
Return to Magritte, Pier and Related Tools
|
1 view|%1 views
| Free forum by Nabble | Edit this page |